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Abstract 

BUILD is a tool for keeping modular systems Ln a consistent slate by managing the construction tasks 
compilation, linking etc.) associated with such systems. El employs a user supplied system model and a 
procedural description of a [Aik to be performed m order to perform the task. This differs from existing tonls 
which do nnt explicitly separate knowledge about systems from knowledge about how systems dnr 
man ipuLatcd 

BUiLLJ provides a &LSUC fteiTltwork fur modeling systems and handling construeLiun requests that makes use pf 
programming environment sp^ciFic definitions, By altering the set of definitions, hUJLB can be extended tu 
work with new programming environments and to perform new tasks. 
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1. Introduction 


Many programming languages; encourage the development of modular systems by allowing the 
Independent compilation uf modules (AllA |Adii S3], C[Kemighan and Ritchie 78], CLU jjLbkov SI], 
Ownmun-Lisp [Steele 84], Mttu (Mitchell 79 , |), This feature can he exploited to minimise the amount of 
compilation. that needs w bt done when some pan of a system is changed. However, as systems become 
Larger li becomes difficult to know caaaly which modules need to he recompiled when erne changes. It Is 
important that the correct modules be recompiled and relinked ■■ a bug caused by ignoring a module that 
should be rebuilt can be very difOcuU to Find, liiis problem is called die ecsns:stcnt construction problcm. 

This report describes null .ft a tool that reconstructs system modules in order to ensure (hat they are kept 
in a consistent state, nun r> does not mndaiy source modules aad will not rid systems of problems that require 
source code revision. However, BOLI) can handle (be many instances. when: some portion of a system needs 
to be recompiled, relinked, lu somehow reprocessed in order to eliminate intonsisEency. 

There arc many Louis that manipulate systems by reconstructing inconsistent parts. Chapter 7 presents 
MftKU [Hcldman T9] and DHt-SvsTiiM [Wtiitrcb and Moon SI], two representative loots, and discusses some of 
didr weaknesses. The fundamental problem with m.ski-., m-f-svsn^i, and all similar construction directive 
based tools is that they operate on systems by using user supplied liMs of construe Lion directives. These lists 
are difTicuEt in understand. BUILD provides the same functionalily as CxiStEug Louis but does SO without 
requiring users to list construclmn steps. 

pl'il.ij derives lire construction steps needed to produce a module From user supplied system imdcft 
'I’ll esc models specify how module^ reference each Other instead of bow they are constructed. TiLULD uses the 
reference information to determine bnw modules depend on each other and how a change Lo one iriudufe will 
effect another, For in-vfcance, if a system medcL specifies that module, refers to macros defined in module^ then 
HUU.D ean infer that a change Lo me-cfwi'f.. implies that module f should be recompiled. Chapter 3 discusses 
system models and chapters 4, and 5 explain how build uses system models to perform construction. 

IklC major Strength Of BU1I lb's reference based modeling system over a construction directive based System 
js that it provides a higher level language for describing system structure, itecausc it eliminates low level 
construction detail and allows explicit declaration offtagh Level system relauori&hips, a reference based model 
is easier lu understand and provides more in formation than, its construction directive based counterpart, 

BUILD separates knowledge aboul systems from knowledge about how systems arc manipulated. The term 
task is used to refer to a construction process such as, compilation or linking that nuttLD may he caLtcd upon IP 
perform, RUll.n- uses jYj.t.k description! to specify how to perform construction lasks- and how the various kinds 
of references that appear tn system models may effect tile COtiSiruCtion requited to perform the task. Using 
the example from the previous paragraph, BULLVs task description for compilation allows it to realize that 
white a change to module 2 implies that module { should be recompiled, a change to rt]Mfwj 1 f J , does not imply 
that mvdu!e 2 should be recompiled. 


TINVCOMP 

ILNYi'XlMP in an example u, modular system, i[ will he used ihriHrghout this rcpiirL Ect preseill different 
srcpccts uf system consiructirtn inch (this. example was adapted I'moii tine used by I'cldmull [Feldman 79f)c 
II\HUW has (wo rTKiji.* modules., a parser ;md a code generator. I he purser is built by YAOC, a purser 
generating tool {Johnson 78a|. ‘Ihe cikJc generator is implemented in C [Kemighan and Ritchie 7B|. ‘Ilie 
purser uud code generator use a common set pf dell nil ions fur shared data structures* These definitions a re 
Combined With the source prugrams during compilation. The Compiled programs are linked ^ilh ;i library 
that Is also subject to change, Figure J-E depius‘ einycOMp’s inier-mudulc reference pattern and figure 
1-2 depicts 11NYC0M p’s cunsmiclkm process. 



Figure IT: iiNYOOMP Entcr-Jdodulc Reference Graph 



Hg.ure IT: Construction Graph Hominycom? 





























Hefercnctr based System Models 

Compare ll.ULiiL n 1-3 which mntains, (he WAK.L' directives fruniNYtTOMI 1 , and figure ]-4 which eiHiLainH the 
lUJU U system model Pur TiNYcmii 1 . While ihc .maKi directives encode iinycomp's construction graph, 
IfUILlTs system model encodes tj nytom p’s reference gruph. 

A reference model can he used in place mf a cunslniciion directive list because all of the in fimnaiimi about 
i in ;i ail MI r miUi.. hsl c.ri :if denied from .1 :yIi-iv.vc i-tiiJcl CusmtlLT : sc third MaKI- directive 

for HNYCOMI 1 : 

COD E G E N . 0; CQDEGFN'.C DEFINITIONS,C 

CC -C CODEGEN,C ft -t COMPILES 

This eipresscs that COOEGEN. 0 a produced by compiling CODCGEN.C. and thal if cither CODIGEN.t vt 
DEI I HI I lONS.C changes, then CODEGEW.C needs lo tic recompiled. This, construction dependency CKisLS 
because CODE G EN.C is cumbined with BE FI ll IT I OMS. C when it ft compiled to pnuluce COO EC E to, 0, 

Ed contrast, the reference based mudcl specifies (hat CODE -Gf NE RaIOR includes DEFS- 
f-INCLUDES CODE-GENERATOR DEES) 

isljet js'h. description Fur comp tfatKm contains die knowledge that the 11N E L LJDE 5 reference implies a. 
Compilalbn construction dependency hetween tndutfrn^ and included files. 


PARSER.t: PARSER.GRAMMAR 

YACt PARSER.GRAMMAR tfYACC MAKES Y.TAB.C 
MV Y.TAB.C PARSER r C # RENAME Y.TAB.C 

PARSER. Oj PARSER.C DEF INI T IQNS. C 

CC -C PARSER. C # -C COUP I US 

CODEGEN.0: CODEGER,C DEFINITIONS.C 

CC -C COOEGEN.C # ~C COMPILES 

TINYCOMP r CODEGCN.0 PARSER.0 LIBRARY ,0 

CC CODEG£N. 0 PARSER. 0 LIBRARY'. 0 -0 TINYCCHHP # -0 LINKS 

Figure 1-3: MakcKiic F'p-r nNYCOMP 


(DEFMODEL TINYCOMP 

(:MODULE BE F5 :C-SOLJRCE "DEFINITIONS") 

(:MODULE PARSER :YACC-GRAMMAR "PARSER") 

(:MODULE CODE-GENERATOR ;C-SOURCE "CODECER") 

[:MODULI LIBRARY ]D-OBJECT "LIBRARY") 

(:INCLUDES PARSER DEFS) 

{;INCLUDES CODE-GENERATOR DEFS) 

(:CALLS PARSER LIBRARY) 

(:C ALLS PARSE R CODE-G E N £RATOR) 

(:CALLS CODE-GENERATOR LIBRARY)) 

hi an re 1-4;. PLILD Model For TIMyCOmp 


I ash Elescrtpiiuns 

Upon ncccipl of a request lei perform a Let, HJtEJl dCrivt:s ii tifrk graph v»'hI lIi models Hie ton'Anm.'Liuft 
Ueps and dependencies necessary Lu perform the task. (ChapLei 4 pitseus »UII I? (ask tlfusdelsand chapter 
S cxpIjijjSF hpw (ask models are derived fmin system niinJels.) Once die Lisk model has been derived, hlii.ii 
analyzes it in order to determine vpItkcIl componenti have changed and what SLt-ps are needed in order to 
saUsly the tusk request. 

null j> provides a static framework for modeling systems and handling, construction requests (hat makes 
use chi' programming environment specific definitions. New tasks ean he added to hun.LVs repertoire by 
altering die set of definitions. 

For example, figure 1 5 wnlaiiw the forms needed to define a task called :LIST-SOURCE-CODE which 
produces formatted listings of the -sou rue modules of a E.isp system, fl his example will he explained in detail 
In chapter 5.) 'Ihe first form allows irtJlt.ll to represent the processing needed u» list a single lisp source file, 
't he second form tells ULJtUl what to do when a . L 1ST-SOURCE-CODE request is received. Ihr last twu 
forms IclE isiJH.n about Die impliLaUunS of Lhe references : CALLS and ; MACRO-CALLS upon the 
i LIST-SOURCE-CODE task. 

Since tusk definitions ate separate Fmm system models new tasks can he performed un existing models 
without additional effort. For instance, once : L 1ST -SOURCE-CODE has hcen defined, null t> will he able to 
handle requests In formal qhc sourre ctsdc for existing systems without changing any system models. 
Cimslraetion directive based tools eannnt be extended m u simitar manner. 


(B E F1NE - PROCE$S-T V PC rLIST-LlSP-SOURCE 
{(SOURCE ;LISP-SOURCE :SINGLE)) 

{(LISTING ;PRESS :5IHSL£ 5DUFTCE)} 

OUTPUT-STREAM 

(FORMAT OUTPUT-STREAM '-TtLIST -A" 

(PAT HMAH[-H]WUS-V E RSTON SOURCE 1} 
f FORMAT OUTPUT-STREAM "^LISTING -A" SOURCE} 

(LIST-LISP-FILE SOURCE LISTING)-) 

{DEFINE-REQUEST-HANDLER {:L1ST-SOURCE-CODE :LISP-SOURCE :PRE) 

{SOUPCI-NODE) 

{ACCESS- SOURCE-NODE f{SOURCE tLIST-LISP-SOURCE) LISTING))) 

fOiriNE-RffESINCE-HANDLER ((:MACRO-CALLS :LISP-SOURCE ;LISP-SOURCE) 

(:LIST-SOURCE CODE :LEFT)) 

{IGNORE CALLED-NODE} 

(PROCESS-REQUEST ;LIST-SOURCE-CODE CALLED-NODE)) 

(DCF INE-RE fEREWtE-HANGLER {(:CALLS :LISP-SOURCE :LISP-SOURCE) 

(:LIST-SOURCE-CODE ;LEFT)) 

(IGNORE CALLED-NODE) 

(PROCESS-REQUEST ;LJST-SOURCE-COOE CALLID-NODE)) 


Kijjfcirc I S: lOcfinition For: LIST-SOURCE-CODE 


2. System Construction Tools 


This chapter fetuses; on two tools that were designed to aid in the management of the -consistent 
construction problem, ilefnre Ihcy air presented himc terminology th.it will he used thmughiiLLt this report is 
introduced. 

I >i ITcrent prisgramining env i ronmenls arc geared Its operate upum di fTcrenl It lids of nhjccls- For instance, 
some environments are designed to operate on files, and others on in net ions. I he term gram will he used tn 
refer to the objects manipulated iti a programming CiLvirumilCnt - regardless of their nature. 

The terminology introduced in this paragraph will he used to refer to the tin da of grains that are 
manipulated dm mg the construction process. Soane grains are the components that are produced by people 
and nut programs te g., programming language source code). Source grains are manipulated by programs to 
product* dtafatf grains (c^., ol»jcct code). Crains that are (he Find product? of the Maiccion process are 
railed gwif grains (c^., executable imaacsof programs}. While god grains are usually derived grains, they cam 
also he scairec grains. I )ciiied grains that are not goal grains are called ititemmlwie grains (c.g., object code 
dial requires linking in order Lu form execulahic images p. 


2.1 MAKE 

MMEl: [Feldman ?9J, available as. part of UNIX 1 , is a simple tool fur managing systems that has received 
widespread use. Make is driven by ms of ccmstmciion directives that form ’‘recipes' 1 for ronsiniciing 
systems. There directives are stored in a text file called a Make File and have the formr 

targe r-GRjir.v i iNGAEDiEwr-GRArw-j ingredient-grain-! rrr 

COMMAND -1 
COMMAND-! 


Each entry declares that 7flffljET-tiRA IIV depends on each of the grains 10 the right of the colon. The 
command sequence below the construction dependency declaration hue is executed in order to construct 
TARGET-GRAIN, There are no constraints placed on the commands which can appear in the command 
sequence. Funheminre, there are no ordering rules for MafccFIle entries. 

MAKE has a simple macro suhsULution facility, A macro is defined in the following manner: 

MACAO- NAME^WA CRO -EX PANS I Olt 

Any instance of MACRO-AIAWf enclosed within parentheses and preceded by a dollar sign (Le., 
$(WACfld-.'jAWE}} is replaced by the text MACAO-FJfAAWSJDAl when the Makefile that includes the macro 
definition is processed. The definition for a macro must precede ail of its lists. 


A Small Example “ TIAYCOW 

Figure 2-i dr p ids the eonsLiuamn process tor TJNVCXJMP and figure 2*2 contains a eOTFespoiidins 
Makefile. Given the MakcFilc, MAKE will perform the appropriate construction when TTNYCOW 
components change. For instance, a change to PARSE R .GRAMMAR will caure a new parser to he derived. 
Compiled, Lind linked. A change to CODEGEN.C will cause CODEGEN .C Hi he compiled and linked. A 
change to U|j Mm It K)n$,C will cause PARSER.C and CODfGEN.C to be compl ied and linked. Finally, a 
change to L I BRA Rif. D will cause linking hut no compiling. 


1 


UNI ?f is a I "iL-.niai k rtf ItiH 1 iihmrilccstS 




Figure J- 1: Construction Graph For tinvoomp 


PARSER,Ci PARSER.GRAMMAR 

YACC P ARStP.GRAMMAR *YACC MARES Y,7Aft r C 

MV Y,TAB,C PARSE ft , C ^RENAME Y. TAB , C 

PARSER.0; PARSERS CEf IN1T10NS-C 

CC -C PARSER .C (F C COMPILES 

CODEGEN.E): COOEqEN.C DEFINITIONS.C 

CC -C C0DEGEN.C 9 -C COMPILES 

TINYCOMP: CDDFGE N.0 PARSER.0 LIBRARY.0 

CC CODEGEN. 0 PAR5ER.0 LIBRARY, 0 -0 TINYCOMP # -0 LINKS 


Figure l-£, MatcFUe ForTTNYCOMP 

The MafceFiie entries are interpreted in [he Following manner: 

PARSER.Cl PARSER.GRAMMAR ... 

pa R 5 E R. c depends on :pa r s e Ft. Grammar, h is created by running yacc on p arse r , G rammar. 

PARSER,Ol PARSER,c DEFINITIONS,C ... 

PARSE R . 0 depends un PARSE R. C and DE FIN JT IONS .C. t( ii treated by recompiling PARSE R . C. 

CODEGEN.Ol CQOEGEW.C OEFIN IT TONS.C ... 

CODEG EN. 0 dependsnn COPE GEN. C and DE FIN IT I0H5. C, It is created by irenmpaling CODE G EM. C. 

TINYCGMP: CODEGEN.0 PARSER.0 LIBRARY,0 ... 

TINY COMP depends (in CODE BE NO, PARSE R .0, and LIBRARY, 0. It is created by FolinVina the system. 












The Construction Process 

MAKH is invoiced with the folkwing UN IX command line Lem plate (brackets indicate optional fields): 
MAKE [-f JUJCfFILF] [GPTJDfl ... ] [MMfr-fflMJN] 

.MAKEFILE Sped fra die name nf the File containing die construction directives^ if itu - IT upturn is used 

Chen M aK ]■: uses the file named MAKEFILE in die working directory. 

OPTION Sped Acs options, like print but do not execute the eotnmat\d sf^wpfjffs or update lhe 

modified dale of the targets without executing any ctwmand sequences. 

TARGET-GRAIN Specifics die name of the target grain Ui be processed, if TAila E is not specified 

then vi a K i : will process the first target grain turned in the MakcFUc. 

VIA K E : begins by constructing a dependency graph From the selected Make Kile. Rsch node til (be graph 
corresponds to a grain mentioned in the Makefile. The children of a node represent the grains (hat the grain 
represented by the node depends on. A icquest to moke a target grain is processed by doing a depth-first 
walk of ihe graph starting with the node Unit corresponds to die largel. At each mule visits, any grains that 
jrre missing (tr whiwe children h.jve changed are updated, 

MAKE compares Ihe creation dates of a target grain and its mgrcdicnl grains ns an approximate means of 
noting when changes occur. Tor instance If TARGET-1 depends tin INGREDIENT-1 there MaKL : will assume 
that INGREDIENT -1 has changed if and only if its creation date is after die creation date of TAflGET-l. 
Since UNIX allows file creation dales to be modified by users, it ks possible to fool Make by changing die 
attributes, However, since mosl people do not change file attributes, the MAkt mechanism is reasonable. 
Without in formal ion ahnut how an ingredient has changed, Max I- canned determine whether a change is 
significant or not. Therefore. MAKE pessimistically assumes that every change (o an ingredient grain will 
effect the target grain, and ii will always reconstruct a target when one of its ingredients has dunged. Figure 
2-3contains the make construction algorithm written in Lisp. 


[DEFUW MAKE {NODE} 

(UOLIST (CHILD {GET-CHILURCH NODE}) 

(MAKE CHILD)) 

(IF {OR (NON-EXISTENT-? NODE) (CHILDPEN-CHANGED-P NODE)) 
(UPDATE NODE})) 

{DEfUN CHIlDREN-ChANGEO-P (NODE) 

{< (CREATION-DATE NODE) 

(APPLY #'MAX 

[MAPCAR 0'GET -CREATION-DATE (GET-CHILDREN NODE)}))) 
Figure 2-3; maxi: Constfuciiun Algorithm 


An Extended Example - LIN T 

The I (Wl system [Johnson '?8b| is presented as nil emended example of using UaKU, I TN I examines C 
SJ.HUFCC programs and detCeLn bug# that must C compilers cariPtft. H K also sensitive tn constructs that arc legal 
bill may not be portable. 

list consists of a UNIX shill script drivel, a SCI Of I [NT Library files,. and two c p rug.rams. Ucforc 
programs me processed by (lie first C program (i,t. the first pass of i.int), they arc processed by the C 
pre-pmeessuf. which handles. miKroCKJiiinsion and siime compiler directives. 

After being processed by lhe C pnC’processor, programs arc senL to Lhe find pass, of IJNT. This pass does 
lexical analysis on the input text. constructs and mautUiins s,ymhol tables, and builds trees fur expressions. Art 
intermediate file ihni consists primes of ASCII (ext is produced. Each line contains an external identifier 
name, an encoding uTthe context Ln which it was seen (use, definition, declaration. ctc.lt a type spocifler, and a 
source rile name and line number. 'I'lie infanmatiun about variables local Ho a function or file is- collected by 
accessing ihe symbol tabic, and examining the expression trees. Comments about local problems are 
produced as detected. I he information about external names is collected in the in termed due file. 

! IM libraries arc collcctwns of definitions of external names !.h, L arc appended lo Lhe intermedmLe file 
generated by (he first pass of i.int. They arc used to provide 3 3 nt wrth li set of defin itions for commonly used 
external iLiin-pt without processing the source that contains Lhe de-fin iliotlS, Tile blEEl commotsly used 
libraries contain (he definitions fur the functions dint are supplied by the UNIX £ run time environment. 
Users can create their own libraries of commonly used names in order to alleviate repeated processing. 

After all the source files and library descriptions have been collected, the intermediate file is sorted tn 
bring mil information collected about a given external name together, lhe second pass of IJNT then reads the 
lines from the intermediate file and compares all of the definitions, declarations, and uses far consistency. 

3 j 'ig-jre 2-4 contains the fdafcTik fur I.INT. The primary point of this OXillSlpk is dwt Mate Files. even for 
medium si?,cd systems like |jvt» arc difficult to understand- The BVII-n description mechanism introduced in 
chapter .1 provides a much simple! way to describe systems. 

The first part of the i.int MateFilc contains macro definitions, 'rhese definitions ate used to specify 
directories (e.g., M), compilation flags (e.g^ C FLAGS), audio group fiksfe.g.. LINTLlBS). The target ALL is 
used Eu name UIl- major Subsystems Of tllC LIN r. The I1CXI cluster Of specifications manages the first pass Of 
LINT. 'Iftcre is an entry for each library file provided With 3 JNT, Each nf these specifics Shat a LINT library file 
is dependent upon a library source file and Lhe firsi pass of LINT. Libraries depend on the first pass uf LINT 
because they arc constructed by it. The targets that Specify management for the second pass of LTNT are 
LPASS2 and LPA5S2,0. 

The LI NT ALL, INSTALL, SHRINK, and CLEAN targets are urn grains at all, rather, they are used to 
initiate installation and removal of LIST, A request to make any of these will always result in the associated 
command sequence being executed because the corresponding files do not exist in the UNIX environment. 
"I hfl use Of non existing grains to force command sequences In be executed is a popular and useful feature of 
MaKT. lhe functionality provided by these target grains is an example of huw COrvSLTuClion tools can be used 
for more than jttsL system eonStructiun. 


h=/u$h:/$hC/L li/riiP 
CFIaGS’-O -DFLIXNAMLS 

L JNTIL1U&-LL1B POP.T.LH L LJfcl-llI. L H IIJtJLH.Ih IL1B-IHP.LH LL L0-LCUPiSF S, L k 


ALL- I F#L5S 1 LPASS? S(L1NTLIBS] 

LPASSI: CGRAN.O KBEF5.0 SCAN.O CONHi.O PflU.G TfitES.O OPTIK Cl LINT .* HASH p 

EE CGRAH.G XDEFS.O SCAN.O COHM3.0 FUND TREES. 0 OPUM. D ILENT.O HASH.D 


1R!f 3, D: J(K}/HAIIIF15J MACD! E £ j(HJjlMUlM j(N]/TREE£.C 
CC -C SfCFLfifiS | -1 J - ]. S| HJ/TREiS. C 
OPT IX.C: S£ Ft]/MANIFEST HACD1FS I(h)/HFILll S[HJ/OPTIH.C 

cc -c sicfi aesj -i. sihj/cfpmh.c 


pi r K' ■ J£w]/hami f[51 naciji eh t r hi ■■ ^ i i : 11 t(H]/FfTN,t 


CC -L ST CFI AOS | -SS{I*E -1. SlMj/PF'N.C 
LCWT.O: S(N)/MANIFEST HACDEFS I£N)/NIFILL1 LNAN3FE5T 
CC ’C t|CFLAGS} -i L ENT.C 


SCAN, 9 ; J(NJ/HAHI Fiji MACLlEFS S| H I /Mh III] £|H|/££AH.C 
CC -C S ; EFLAGS]! - ESCN] E ■ HMJ/SCAN.C 
IDEF 5 . 0 : Sf M j/HALl] FIST 3 [MWHFHE I MACOE FS S(M)/*KFS .£ 


CC -C tlCKACS3 -Et(H] -t. 

Cftmi.Q: Ifhji/wAU] TLST SjM'i/NI ]L [ 1 
CC C KCFLAGS] -E. ]S[HJ 
CGRAK 0 ({ H ] /HAN ] H ST tlUJ/HI.IL F L HAjCDUS CGKAH.C 

CC -C I(CrcA££J - ll(Hj -E. CCflAH.C 


t(MF/SQlfS.C 

t(NI>/C0HHDh HACDEFS S(M)/CCHN1 .C 
ijNVCOHHI.C 


CHAH C S-jMJ/tCRAH T 

YACC J(M|/CGRUl. V 
H <f V. TAB C CGflAH.C 


LLIfl-POftT , Lit: LL3S-P0BT LPASSI 

-j/LlB/CPP -C ‘GLINT LL EC-FORT 1 ./LPASSI -iFLIV > LLIO-PQNT.LN J 
LLIB-LH.LM: LLIB-LH LPASSl 

/UH/CPP -C -DLINT LLIA-LH 1 ./LPASS1 -PUV > LLiH'LW.LN ) 
LL1B-LMP.LN: LLIB-UMP LPASS3 

-(/LlE/tFP -C -DUNE tite-SKP | -/LPASSi -PUY > UIS-LHP.Lh ) 
LLIB-LC. LSI: LUH-LC LPASSi 

-(/L3B/CPP -t -E1LTNT LLTB-lC 1 ./LPASSI -V > LLlB-Lt.LM J 
LUB-LCWH5I-S EH: LL [H-LCURSfS LPASSI 

-(/13B/CPP < -DUNT LLIB-LCURSES | ./LPASSI -V > LL3B-LCURSES.LN ) 


I PASS?! I PASS?.0 NASH.0 

CC LPAS52.Q HASH.Q -0 LPASSI 


LPASSE .0' STM]/MANIFEST | HAN] FIST 

CC SiCFLAGS) -C -I- LPASSi.C 


LINTAIL: 

LINT -HPV -3 -JS(H) S | H) .■'Lfi KAN C S(M)/XDEFS.C SfHT/SCAH.C \ 
S(H)/PFT*.C J(M}/TPEES .C Ji;H}/QPTI».C LINT.C 
INSTALL: ALL SNELL 

IN$TAIJ -s LPASSI /iLKRSL [H/Lim/L mil 
INSTALL >S LPASSi /(iSR/LIfl/LTNT/LINT2 

FOH T IN LLIB-*; 00 INSTALL -C -H 6*A ttr /U$H/I IB/LINT; IW*! 
t»S IAI I -c SHU; LI /USK/lFI H/LlNT 

SHRINK; 

PM -F *,Q 

LL L Ah . MIIKJ YK 

RH T LPASSI LPASSI CCPAN.C S{LENTL]0S> 

3 -iRUTC 2 - 4 : Makefile Pot IJNT 


-D LPASSI 


[tendencies 

J^linj.vL'd in ttTiiiv of CtWtSlfllClIon. "ITiC fundamental problem will! MA.K.1-: ts that it forces users 10 
TTuuiipubtO lists of eonsLrucuon directives, hmplc do not normally dunk alum' systems in terms of the Steps 
used to ccmsiruet them. and there bur these iisLs are difficult to understand. mak.Iv should preset a more 
natural user interface and (hen wort from the user supplied infimikm towards the eunsirucuoii information 
that el requires. 

MAKL does not include an adequate means fur Saving and reusing common construction patterns. The 
introduction of such a tlicilhy would shorten MakoliLei siiteC CiUnmon patterns would he replaced wilh single 
identifiers*. the definition nf the identifier would document and highlight the imended construction pattern. 
The functionality described in this paragraph is usually provided by a macro mechanism, however the MAKE 
macro facility is Lou simple “ It does not even allow for parameterized maerm. 

No underlying task descriptioaSr Syslqros (li.it keep knowledge abtmt construction separate drum 
knowledge about systems can he emended by adding tn the conHtnjctlun knowledge with out altering cxisttng 
system models. 1*11 man [Pitman 841 discusses the importance of separdting knowledge about systems from 
knowledge about construe Lion tasks. MAKi: dues not use task descriptions at all and cannot he extended 
without changing existing MakeFilcs, 

I manned i.Mc grains are rvfcmiewl, MninoiifKTS can only change systems by manipulating source grains or 
requesting that gj*iil grains he constructed- Maintained do not manipulate mDermcdialc grams and it would 
he Pice if these grains did not need to appeal in .Makefiles. 

All snurre grains nerd not be referenced. MAKJ: allows System descriptions l£> omit source grains that am 
also goal grains since there is no command sequence that uses or effects ilttin. Rif example, (here is nothing 
LhaL forces UMIX Shell Scripts to he included in MakcFtlcs, The absence of references to Shell Scripts would 
be a seriousOdfljssion if someone were using A MakcFilc to determine which grains needed to be copied when 
transporting a system. 


2.2 DEPSYSTEM 

i'ji ;i s.vsn i m [Wciiarcb and Moon B11 ts a ctmstnicli™ directive based mtkl dial is used to instill and 
nt:u»Liin I .ivj Min;hint software, The I >1 i svs- !U analog to MARIAS Makefile is billed a s^Lem description, 
ntil EYS l MM system descriptions c^inUii n a mis Lu re of system modeling in formation and ecmHLnjctkin 
dircciiwtSw IH-TSYSHM requires llut comm nd sequences (citlled transformations) be formally defined before 1 
Uiey cite used; this is different frnm (he \JaK 1 : approach of allowing unlimited use of UNIX command 
sequences. 

System descriptions arc made by DEF5-YSTEH macro. Calls to DE FSYSTEM have the form: 

(DCF SYSTEM SYSTEM-NAME 
{KEYWORD ARGS ***) 

[KEYWORD ARGS .. .) 

Hie options Sc-leclcd by die keywords fail into two general categories: properties of the system and, 
transformailans, 

Ihcie art three nwin WJ^YSIPM property keywords: 

; NAME Specifics a "pretly" version of 5fS rFM-AIAWE for use in printing. 

:PATKKAME-DETAULT 

Specifies a local default wiLhin Lhe definition of the system for strings to be parsed into 
pathnames. 

; MOfl lJL E Assigns a name to a group of files withi !3 the system- 

A transformation is an operation, such as ctanpilmg at Loading, that takes one or more files and performs 
some operation on them. There are two types of DEFSYS1EM transformatinns: -simple and complex. A simple 
cranstormaLaun is a single operation OP a module, such as compiling it ur luading II A complex 
Lranstormalaun combines several transformations: for example, compiling and ihcn luading the results of the 
compilation, 

The general format of a simple dims format ion is: 

{NAME INPUT PRE-CONDITIONS) 

NAME The name of the transformation to be performed on the files specified by INPUTr 

Examples of transformation names aic- ; FAS LOAD- and :CQMPILE“Lf?AQ“ 1 N IT (these 
transformations arc described below). 

INPU T A module or nested transformstioo. 

ffl£-ftM0fri0N5 

Optional. Specifics transfurmatums that must occur before tlwr current transformation 
ilsclf can lake place. The format is cither a list { NA M f WfJRtlf f -NAMES . . . ) , or a list of 
such lisLs. Kaeh uf these lists declares Lhat the transformation NAME must be perFnnncd nn 
die named modules before the current transformation can Lake place. {The Lisp Machine 
documentation calls preconditions rityjxvjdWjrifj.) 


JliL’ fulls wing simple iransruraiaiums mc pre-defined: 


iFASLOAD S-dfltfs the indicated file when a oe^ver version Of the fi]c ciisls than was read into Efto 
current environment. 

: COMP HE Compiles the indicated file when the source file hjis been been updated since the compiled 
code file was written, 

Unlike simple transformations, complex transformations du not have any standard form. The predefined 
cumplcx transluniiLiLiuiiS arc: 

:CDMPItfi“LOAO 

Compiles and then loads the input fiks. It has die forint 

£:COMPILE-LOAD INPUT COMPILE-CONDITIONS LOAD-CONDITIONS) 
and is exactly the sttmc as 

(tF'ASLOAD ( lCOMPILE INPUT COMPILE-CONDITIONS) LQAD-QQNQTTIONS} 

; COMP IL £ -LO A □-•-1NIT 

ClsmpLlcs and loads (lie input files. This (xansfiirmalion is sensitive to changes made to an udditkliul 
dependency list, It has (he form: 

{iCOMPILE-LOAD-lNIT INPUT ADDITIONAL-DEPCHDENCIES 
COM P ILE-PRE-CONDI T IONS L GAD - PM - COND IT IONS) 

INPUT will tw compiled and loaded whenever its source file or any of (he modules listed In 
AUDIT TONAL -DEPENDENCIES arc updaLed. Note, the AUDI TIONAL-DEPINOENCSE S field of this 
transformation specifies die same kind of Construction dependency as MakeFilc entries dO- 

El B important to distinguish between transformation dcelaraLiuns and tra ns formal I on references. 
Transformations are declared by keyword lists m calls to DCF5Y5TIM. Transformations ate referenced in 
precondition lists, The (jansfurtnatLonS referenced in A pre-condition list must be declared somewhere in the 
system description. 

defSysthh eo pi tains a Facility For de fining new (ransformatinr.K. S'ew simple transformations are defined 
using the DEFIN£-SI«PU -TRAMS FORMATION macro. Calls have the form: 

(UEFtHC-Sl HPL E ■ T R> M Sf 0 RMA11 ON AW ME FJJlVCTTDW OE FAULT‘-CONDITION 

1NPUT- fILE -TVPES QUTPUT-PILE- TYPES) 

NAME The name of the transformation being defined. 

FUNCTION A SuncLun to be called wtlffl the trails formation is performed. 

DEFAULT-CONDITION 

llie function (hat is called in order to- determine if (he transformation should he 
performed. 

INPUT-FILE-TYPES 

Specifies the types Of the input Files to Ihc IranstoumBtion. Lisp Machine file type 
■specific jus ions are filename extensions, [e.g., rl l[£p“ or ’'bin 1 '). 

OUTPUT-FILE-TYPES 

Specifies die types of the OUtpul files produced by the transformation. 

Foe example, to define a simple (ran storm a [hot tailed rLISP-YACC tllill calls f ISP-YACC to derive parsers 
wrir(en in Lisp from UNF grammars, the following definition could he made. (If a Utility like Y ACC were 


desired isn the [.ftp Machine it would probably be implemented with a maqre and not a separate parser 
gcnciaiim tool.) 

£ D E FIHE ~SIMPLE- T H AN 5 FO RHATIQ N ;LISP-YACC If LISP-TACC 
IT FILE-HEKEft-THAN-rILL-P f tGRAMMAR) f;LISP)) 


LISP-YACC will be invoked whenever Ihe input tile (i.C„ the grammar) is newer than the output Elte fi.e., the 
parser). In other words, die transformation will he performed whenever the source file is updated. Notice 
Otar this uatisfinrnaiion relies on grain creation dates in ocaeily the same wap that vuKt' does. 

Complex transformations arc defined as Lisp macros, Here is ihe definition of the : COMF1 LE-LOAft 
transform a Iinn that w® described earlier: 

£DEFHACRC (;COMP!Li-LQA0 DEFSYSTEM-MACRO) 

(INPUT SDPTIOHAL COHPJLE-PRE-CONDITIONS LOAD-PRE-CQhDITIDHS) 

"(:FA5L0AD (^COMPILE .INPUT .COMRIlE-PkE-CONDIT1QN5) 

.LOAD-PPE-CQNDIIIONS)) 


\ Small Example -TINYCOMP 

Hgurc 2-5 contains tile Dn-SYSriW description for a Lisp implcmcn union of T1NYCOMP. 

(OEfSYSTEM T INYCGMF 

(;MODULE CEFS "DCFIN ITIONS") 
f:MODULE PARSER "PARSER") 

{:MODULE CODE-GENERATOR "CODEGEN’) 

{:MODULE LIBRARY "LIBRARY") 

(:FASLQAfl DEFS) 

(r PAYLOAD LIBRARY) 

f :CaMPILE-L&AD-lNIT CODE-GENERATOR {DEFS) ( : F A5LQAD DEFS)) 

(i COMPILE-LOAD-IN IT fiLISP-YACC PARSER) fOEFS) (,‘FASLOAO DEFS})) 


Figure 2-5: DEF 3 Y 5 T 1 IM DcscnpHicin ForTTNYCQMP 

The TINYCOMP description contains a set of mediate definitions followed by a series of transformations. 
The; transformations m Lhe dcscnplion have the following interpretation: 

{t FASLOAD DEfS) 

Specifics Uiac DE FS should be Loaded whenever it is updated. There arc no pre-conditions to be satisfied 
before (be loading can take place, 

(ifASLOAD LIBRARY) 

Specifies dial LIBRARY should b£ loaded whenever it is updated- There are no pre-COfidllJons to be 
satisfied before the loading can take place. 

f :COMPILE-LOAD-INIT CODE-GENERATOR (DEES) {: FaSLQAD DEF5)j 
Specifics Lha( CQDE-GFMRATOR should be be Compiled and loaded whenever it nr D£ FS changes. Before 
the compilation can Cake place, BE FS must be leaded. 

(:COMPILE-LOAD-IH1T £;LISP-YACC PARSER) (DEFS) (:FASL DAD DEFS)) 

Specifics that a parser derived from PARSER is to be compiled and funded, A new parser is produced 
whenever PARSER changes, The compiler and loader are invoked whenever DEFS or the derived parser 
changes. :LI5P-YACC will not he invoked if only DEFS changes. Prior to Compilation, DEFS must be 
knitted. 



The f iGnsdruction Trwess 

Systems previously modeled ui.[h DETSYSTFM are constructed by culling MAKE-SYSTEM. Calls have the 
form: 

(MAK.E-5Y5TEH SYSTEM-NAME gREST OPTIONS) 

SYSTEM-NAME Specifics a system previously modeled with DEFSY5TCM. 

Of f IQtfS Specifics options like print she iransfimmitkms that WJUldbf done but dan'i do thern and- 5P 

forth. 

lhe construe Lion dependency graph Specified by (he transformations and pre-conditions in the 
Ulil-SYSTEiM description of iVSTfM-WyiMF is analysed in order to determine wbiri construction needs to be 
done, Each (transformation is applied by first applying any iiuiisrtHrrrLaiions referenced! as pre-cemdilions, and 
(hen updating die input module if iL, or ary modules listed in additional dependency lists* have hecn changed. 
Notice that the transformation upplicatiunS are ufdcncd by the pie'Condition fists. 

Like MAK.lv, T)FJSY5ni : M U8CS simple functions based on file creation dales tn order (o determine when a 
module should be reconstructed. However unlike MaKK, niil-tSYSTliM allots Lhe optional specification of 
predicates that control when construction is dinte. t he new predicates can replace the simple ones dial ate 
Supplied with LH I5V5TTM. 

nrj systum includes a patching facility. It allows small changes to be made to a system without invoking 
the iii:psysti:m transformation/dcpendcncy mechanism, Each set of changes is stoned in a. patch file that 
typically commits, ne* Function definitions or redefinitions of old Functions. Each patch is assigned a number. 
If a system contains patches, then the patches arc loaded, in order, after Lhe unpatEbfcd version of the System iS 
loaded- 


An Extended Example “ LINT 

lhe iw-Lsystlm description for a Lisp implementation of LINT is presented in figure 2’G, Although (be 
Dty-SYSTtiM description is easier to understand than the C'ornespnndir.g Makefile { figure 2 - 4 ), it is still difficult 
to understand. 

The ; BUI I U-LINT-L IBRARV IransFnrmarimn is, anumed to have been defined and has (he form: 

{ ; BUI |_0’LI WI-L IBRARV INPUT PRE-CONDITIONSy 

It constructs UNT library files from LINT library sources, The transformation allows (he optional spccLfkajtion 
of precondi tions, and is applied if either IITPUT, or the first pass nf UNT is updated. 

The first keyword form in She LINT DGFSY&THM description specifies a System-wide default directory. The 
next block of keyword forms declare die various modules which comprise unt. The final block of forms 
declare 1be transformations used to CO (1 SI met UNT. Notice that 35 transformations are nested and pre- 
eondiLioiLs are added* lhe transformation declarations become increasingly difficult to understand. 


Deficiencies 

Eli rased in MB of COKKlTUCttoH, like MAKF, fn-FSYSTFM is a construction directive bused tool. This is 
the primary reason that cn-r^Yfiii M descriptions, although easier Lei understand than MukoFilcs, ate still 
aw k ward. 

One reason that DIT^YSTI^i descriptions are easier (o understand than MukeFilcs is because HFE^YSTFM 
is not purely construction directive based, iild t*YStj-:mT ; MODULI, declarations allow fur the fcogieal grouping 
of grains into IlsgllCf level modules, This grouping abstracts awny from low level construction informaLum, 
and p new ides a more natural w ay Fpr users hi describe system* than makti does. 

IIFI-'SYSTFM supports (he sharing of common cnrsLruction patterns ihnougli the dectaratiLHli of 


(DEFSYSTEM LINT 

f : PATHJJAWE- DCFAULT VUSH/SRC/l Ifi/HIP 8 ') 

{■MODULE DEf INUIONS-I ("KACDEFS" "MANIFEST 1 * "MFILEl" "LHAN IfEST*)) 
{:MODULE DE FIM IT IOHS-2 ( " HAH IFE ST " ’ LHAR I f t St" ) ) 
j:MODULE PARSER "CGRAH") 

([MODULE PASSl ("XOFFS H *SCAN" *CDMMi" "PFTN" "TREES" "OPT1M" 

"LINT*' "HASH")) 

(:MODULE PASS? ("LPA5S2" "HASH ") ) 

([MODULE DRIVER "SHELL") 

{[MODULE LIBRARIES {"LLIB-PORT" "LLIB-LC" " L L10 -LM" h LLl6-LMP h 

"LLIB-LCUfiSES")) 

(:FASLUAD DEF1NIT IONS-1) 

(:FASLQAD DfF!NITIONS-2) 

(:CDMPILE-LOAO DRIVER) 

{ [COMPILE-LOAD-1 HIT PASS1 (D£f I N IT IONS-1 ) < ; r A.SL0AJ3 DE E 6 N If IONS- 1)) 
( :C0MPILE-LQAD-II11T PASSE (DC F! N 3 T IONS-2 ) {:FASLOAEl DEFI N IT IONS-E )) 
{-COMPILE-LOAO-INIT (;IISR-VACC PARSER) (DEFINITIONS-l) 

(:FASLOAD CEFIMIT1DN-S-1)) 

([BUILO-LINT-LIBRARV LIBRARIES (zfftSLOAD DRIVER PARSER PASS1JJ) 


Figure 2-6; TiFl^Y&TrM Description For [.[NT 

transformations. Ill is. makes REI^YSTEM system descriptions easier to produce and understand Efran 
MakeFUes. However. since if K possible to avoid the decimation Of a complex. transformation by using nested 
transformations. eh^v^tiim sdll allows for common patterns to t»e repeated instead of shared. 

No underlying task descriptions. Although nH^YsriiM bos embedded knowledge about Lisp compilation 
and loading it does nut include a mechanism-tor describing construction tasks and therefore cannot he 
extended without groat difficulty, 

Intermediate grains are referenced. KFSVJTCM do® not differentiate between smrrce, intermediate, and 
gonl grains. In general. intermediate {trains are hidden by cnmplcx transformations. Fur example, there are 
no references to intermediate grains in figures 2-5 and 2-6- White EmrsYSTiDJ docs not force intermediate 
grains In be included, it dWJS not prohibit them cither. 

All source grains need not he rcFcrcnccd, Ir. a Lisp environment, nothing can he ured heFnre rt is loaded. 
This means that any gram Lhat participates in a Lisp system will he involved in some Donstruction, and 
therefore, it is not as natural tn omit a sourac grain from a DE1-SYSTFM description as it :s to omit one from a 
MakcFilc. This difference between MAKJi and DCTSYSTEM comes Emm diffierenceS between the UNIX and 
J jsp environments, and not from important d i Florences between the two tools. 


Other Tools 

De-Remer and Kron introduced the terms programming-in-dic-largc and pnogramming-in-the-small 
[l>eRcmcr and Kron 7fi| to distinguish between die writing of modules and the stntcturing of modules into 
systems. Consistent construction is just one pfugranuniitgun-the iivrge Ksuc. others include source eude 
management, module interconnection specification. and version control A brie!' summary of these other 
issues And projects that Focus upon Lherri is presented here lw completeness. The consistent construction 
oompnncnLs erf these projects do not differ from makf ornpi-TiYSTHM in any significant way. 

When Several people are working on a system simultaneously, it Is important to regulate access to the 
source code modules in order to ensure fbat Msmcunc dues not attempt to modify a module while someone 
else is modifying that same module. A enmmon scheme is tn implement a libw/ian (hat regulates access in 
system comptmenls via a chcck-in/check-uut mechanism. In short, only one person is allowed to chedt-uui a 
module for update at any time. Anyone can rend a module a< any time. Source code management systems 
,iro dcreriih-il hi die iolluwihg ]iapci^ IKitdikiiid 7j, CfUjolof, eL .if tHi. 11oistey and Lynch 79. Lewis.H]J- 


All of the problems mentioned above arc compounded if the pncssramming environment is distributed 
over a nocs*.ork. Schmids Addresses these isues [Schmidt 

ft is often Lhc CHSC ih.ii there arc families of -systems being managed. h'or example there may he several 
public TCleiiSCS of a system. internal releases, experimental VCrSiirrtS and Su tm. It is also OEimrnun for there to 
be several versions Of a system intended to run on different hardware con figurations. liaeb member of a 
family of software systems usually shares many ctimpoiiLiiCs with other members of the family. Maintained 
of such families need to worry about whieb versions of which modules a re used in each member of the family. 
I'ichy and Coop rider atiac-kcd Uio problems associated with the representation and management of software 
families [CtKjpriddr 79, Tiehy BA, Tichy £4]. 


3. The BUILD Reference Le\cl 


L It is- chapter introduces hlTt.b's reference based system modeling scheme. flunu system models ate very 
easy 1 lo interpret because (bey contain nothing more than declarations of thVw grains arc grouped CO form 
modules and hem- these modules refer to each other. Although ihcy do not present any construction 
dependencies explicitly, they can be used, to derive all of ihc construction infermatami found in construction 
based models (see Chapter Construction models cannot be used to derive foe reference information found 
in reference models, licfencncc models are far less confusing than the construction based models because 
they are written in a language that replaces kiw level grain, construction information, with higher level inter¬ 
module reference patterns. 


3.1 Modules 

it rS often the ease that groups oF grains are conceived as one logical entity hut ate Split Up fe.g. into files.) 
for other reasons. Modeling schemes that represent systems only at the Level of the individual grain do not 
have the ability to express tins Lind of grouping. The module construct used by muni (and DClSVSrrtM) 
allows these groupings to he made explicitly in system dcseriplicm 
nuu.D module declarations have the Form: 

{rMODULE MODULE-NAME GRATN-TYPE & REST GRAINS) 

MODULI “NAME. The name of a module, The name must be UitLC|ue wifoin the system model. 

GflAIAI-TVPf The name Of a grain type recognized by BUILD. Each grain is assumed to be an instance of 

this type. 

GffAINS TTie names of the grains thateompriw the module. 

The following form declares that MAI Pf is a Lisp Suutee module composed of the single grain MAI N , LI SP, 

(: MODULE MAIM tLISP-SOUftCE "MAJ«.LJSP"} 
and the form: 

( : MODULE QEF5 ;C-SOURCE "DEFINITION5-1.C* H DEF INI TI0N5-2 , t~ ) 
declares that DEF5 ts a c source module with two grains named DEFINITlOtlS-I.C and 
0EFINni0N$-2.C. 

hljild can use grain type in Formation without considering module references to determine a great deal 
abmat the construction of grains. For instance, lU'ttJn knows how to invoke [he correct ctunpilcr on C Of Lisp 
source files or how (o construct LI>T library files from library sources by Hulking grain type information 
alone, 

3.2 Kt'ffrences 

DUJI.I? infers crmstmetion dependencies from reference assertions by taking advantage of the fact that 
construction dependencies are caused hy references between modules. If two modules do not refer to each 
other, then it is impossible fin there lo he .. construction dependency that involves them. When the assertion 
is made that fitvdulcj refers to mttdule T (tUttJ) pessimistically assumes chat each grain in module { refers to each 
gram in module^. 

References with the ■same name may be handled differently depending upon (Ire grain types of the 
modules invoked in foe rcFcrentC- For instance, toe cafh reference between two Lisp source modules is 
handled difTercritiy than toe calls reference between two C source modules. 


m m ■ i K-It.-1ci ilC derlaramsns provide Jbr the spccilicatinfl of rcfaeiKCH. between modules. No meaning is- 
attached [h i the U rdfi ling nI' reforencc declarations. Kercrencc declarations have the form: 

(REFERENCE LEFT-ELEMENT Rl GHT-ELEMENT) 

RE FERENCE I "he name of a reference recog.ni.,red by HdJii.n. 

LtFT-ELEMENT A module name Of list of module names. All module names used in a reference 
declaration must have been declared in a module declaration. 


fflGHr-fLEHfllir 

A module name or list of module names. All module names used in a reference 
declaration must have been declared in a module declaration, 

The use of module name lists as cither of the clement of a reference declaration is Syntactic Sugar that is 
equivalent Lu the set of reference declarations, composed by enumerating REFERENCE-NAME with each pair 
:n the cross product of the light and left element lists. Fnr example: 

(:CAt.LS (A B) (0 E}} 
is equivalent lo: 

( :CALL$ A D) 

( [CALLS A E} 

( [CALLS ES D) 

([CALLS 6 E) 

Here are sume reference triples and the construction dependencies that they imply: 

([CALLS LISP-SOURCE-t LISP-SOURCE-2) 

Asserts that LISP-SOURCE-1 contains functions that call LISP-SOURCE -2 and implies that 
L7SP-SOURCE-2 will need to be Loaded in order for l ISP-SOURCE -t to execute. 

( ;MACRO-CALLS LJS-P-SOURCE -1 LISP-SOUHCE-2) 

Asserts that LI5P-SDURCE-1 ust-s macros defined in LISP-SOURCE-? and therefore LISP-SOURCE-2 
must he loaded in order for LISP-50URCE*1 10 compile prepay. Ibis reference implies that if 
LISP-SOURCE-2 changes, then LISP-SOURCE -1 will need to be rq-compikd, 

(:CALLS C-SOURC£-i C-SOURCE-*) 

Implies that the object grains compiled frem C-50URCC-2 (as well as the object grains from any mudulc 
that C- SOURCE -2 need to be linked into any executable image that is to inetude the ohjncl grains 

from C-SQURCE-1. 

(:INCLUDES C-SOURCE-1 C-50URCE-2) 

Asserts that C- SOURCE-1 eonmitre the contents erf C-SQURCE-Z, This referejice implies that whenever 
the included module, C-SOURCE-Z, changes, the including module. C- SOURCE -I, needs to be rebuilL 

ivuit.n uses triples tolled reference signatures) of the form 

PREFERENCE-NAME LEFT-GR.A JN-TTPE-NAME fflGtff-GRA Itt-TYPE-NAME > 
lo identify references. FHUll.O uses grain type Wformation to distinguish between references that have the 
same name but apply lo dilfcnmi grain types, A given implementation of ML III. 11 will define the reference 
signatures tltat ire commonly used in the environment that min it u working with. Chapter 5 describes how 
new reference signatures may be added m builh. 


3.3 Models 

I lie .ll'-'cic 1 a I i":mv. nf it injii 1 5 system description is: 

(DEFMODEL MODEL NAME SHE5T DECLARATIONS) 

'I here J*Tic four kinds t*f {fccknrtiorvs tha| may he inf hided in H DEFMODEL II inn 1 module^ reference, 
default pathname, and default module. Module and reference dcclaratiiww were deiicribed earlier in ibis 
chapter, 1‘he default pathname declaration allows fur the electa nation of a pphnumc to be used nS a template 
loi emiipletN'if. filenames. It has the ruirn: 

([DEFAULT-PATHNAME PATHNAME) 

lhc default module declaration Is urerf to declare a module US ihe default module fur llUIIU to operate on 
when eunafucliUh requests for die system are made. [(. has lhc form: 

( : DE FAUl T-MOEiULC NODULE-NAME) 

Figure 1-1 curtains Lhc DEFMODEL form fisr Tl NYCOMP. ITte fir&l four declarations are module 
declarations that Specify the grains and grain Lypes nf the-system modules, The tiiS4 throe declarations spicily 
die references between the modules n Lhc system. figure J-Zconiams Lhc Dt fmuuel fonn fur lint. ITie 
model is lunger than the UNYCtJMP model buL no mure cum plicated. 

(DEFMODEL TINYCCMP 

{:MODULE D£FS :C-SQLIfiCE "DEFINITIONS’) 

(;MODULE PARSER :TACC-GRAMMAR "PARSER") 

( :MODULE CODE-GENERATOR ;C-SQUBCE "COOEGEN" ) 

( :MODULE LIBRARY iC-OBJECT "LIBRARY 1 *) 

{[INCLUDES {PARSER CODE-GENERATOR) OEFS) 

{[CALLS PARSER (LIBRARY CODE-GENERATOR)) 

([CALLS CODE-GENERATOR LIBRARY ) ) 

FUgure 3-1: bUlLD Model For iinycdmp 

(DEFMODEL LINT 

(:DC FAULT-PATHNAME "/U SR/SRC/L 3 B/MIP") 

(:MODULE DC fINIT IONS-1 iC-SOURCE 
"MACDEFS" "MANIFEST" ”MF TLIt" "LMANIfEST"} 

{ : MODULE DEFINITIONS-? iC-SOURCE "MANIFEST" "LMAN IFEST *) 

{:MODULE PARSER [GRAMMAR "CGHAMT) 

{[MODULE PASS-1 [C-SQURCE "LINT'") 

([MODULE PASS-? [C-SOURCE "LPASSZ") 

{[MODULE SUPPORT-1 :C~SQURCE 
’ H D-E F S" ’SCAM" "COMHtl" ’PFTN" ’TREES" "OPT IN" "HASH” ) 
f[MODULE SUPPORT[C-SOURCE "HASH") 

([MODULE DRIVER rSHELL-SCR1PT "SHELL”) 

(;MODULE LIBRARIES [LINT-LIBRARY-SOURCE 
"LUfl-POAT- "U3H-LC’ h LLIB-LM" ’LL.IB -LHP” "LLIB-LCURSES") 

{:INCLUDES PAS5-1 DEFINITIONS-!) 

{[INCLUDES PASS'? DIF III | TJOHS-2 ) 

{[CALLS DRIVER {PASS-1 PASS-2 LIBRARIES)) 
f[CALLS PASS-I (PARSER SUPPORT-!}) 

([CALLS PASS-2 SUPPORT-2 J) 


Heuxe >2: build IX’seriptiuh Fur r jnt 


4 The BUILD Task Level 


lilts diaper describes Lhc t*sk level rcprosenlalion of systems used by iiuii.n, A task level mcidel n. 
derived from die refer cnee level rnevdei fur each request Lb at nuiPO receives, Tht derived model es then used 
to handle the request, { l hc phrase tojfc krel is used in place c»r the mow qiodfic phrase omirui‘tn») fcrti 
because IHJtt i) is used fur mole L:;lm just construction.) 

HUH n task level imrdcls are acyclic directed graphs ivith Lwn Vind-S of nodes; g'Hoda; wh.ch represent 
grains, end p-nuties which represent [he pmosKCS used to ei instruct grains. lasaf nudes represent source 
grains, and nx)L nodes represent goal grains 'file Link between grains and the processes that use UiL-m is 
modeled by linVinp, the- g-nodcs representing grains It) Ibe p-nthJn representing the processes dlat use them. 

Kignre 4-t contains a portion of the Ensk graph used to represent Lhc compilation of Parser, lisp, a 
grain from j l.isp implementation of JINYfOMP, This example aShtfttK thill PARSE It, L ISP is a st«urce grain 
and Ignores the fact UlitL in TUN YC UMI\ PARSER, LI 5P is an intermediate module produced by L JSP-fACC, 
The ellipses reprcseni g-nodes and Lhc rectangles represent p-nodcs-. 'Ihcrc are two source nodes. 
PARSER. LISP and QEFS.LtSR. and a si tlgle gnat node. P ARS E R . I MAGE. 

Although Hie use of an acyclic directed graph lo represent task pnfsecsKing is n^ unique (mam: and 
CTITimRM use similar rcprcsentntiJins) ihc derivation of task graphs from reference models k novel. 



4.1 Grain typos 

Grain type objects are used 10 represent the classes of grains used by the environment chit build is 
working with, They are u&ed to represent atL of the kinds nf grains that are manipulated by the underlying 
environment, whether they are fils or not, For instance, the grain type j LISP -1WAGE is wsed to represent 
Lhe objects that result fnym loading files into the Lisp environment. 


JlcfininjjGrain Types 

G rai n types a re defined * ilh PE f IN L -G RAI *J - T i PE and dcfimtmnK have the form: 

(QEFINE’GfiA Ifl-IVPE NAME SOPflONAL FlLENAHE-E ^TENSION) 

NAME J he name of die grain type being defi nod, 

FILENAME-EXTENSION 

lhc default filename attensiun fur grains of this type. If this field is null then BLiit.n 
assumes that groins of this ty|>c are not files. 




















1figure 4-2 ciiniiiins [he grain i_vpc deli id [ions used io model I .isp systems, 'Hie :LISP-.‘SOURCE and 
:LlSP-BIWARV groin lypcK correspond in iik-s and hence Llicir definitions include default filename 
cmensioits(dw I .isp Machine uses keyword symbols to represent filename ex ten shun). 'Ilie :LISP-IMAGE 
grain type is iral asMiiKiaLed! with files ;md therefore has no default filename CsLeivsIon. 

(DEFINE-GRAM-TV PI ;L ESP-SOURCE :IISP) 

(DEFINE-GRAIN-TYPE :LISP-BINARY :BIN) 

(DEFINE-GRAIN-TYPE :LISP-IMAGE) 

Figure 4 - 2: Grain 'J ype J Jcfinilions fur I .isp 


4,2 G-nodes 

Cr-nudes represent grains in cask. graphs, they ton Lain the following information: 


IVAMF 

TYPE 

MODULE 

CREATOR 


The name of die grain represented by this g-nnde. 

The grain type object that the grain represented by thisg-nodc is an instance of 

Optional. The module that includes the grain represented by this g-nodc. 

OpiloitaL The p-nndc that represents die process that created this g-nude. This field wilt 
be null if the g-node represents a source grain. 


USERS 


A listofp-nodes IbaL depend on Oils g-nodc tn fiEL an input rote. 


JNGflfDIENrS A list chat represents the source grains used to produce this g-nodc. Each element of the 

list is a pair containing the name and c nation -date of an ingredient grain 

CREATE-DATE A time Stamp thaL represents Lhe lime and dale when the grain that is represented by this 
g-node was created. 


4.3 Process Types 

Process type ohjiKls contain the information pc naming to classes of process instances (represented by 
p-nodes}. For example, the 3.isp Machine implementation of PJTLD includes process type objects for I.Lyp 
compilation and J.isp binary file loading. 

' I Tic grains Lhat are used and produced by processes- are paitdcuned aceording Lu the rules that they play in 
them. Grains thaL processes use are said to play input rales. Grains that are produced by processes are said tu 
play i Tutpui roles. 

Process lype objects contain rale descriptions for each of their input and output roles. Role descriptions 
contain the following information: 

NAME the name of Lhe rule. 1 l must be unique within the process type being defined. 

Q ft A f ft - fVPf The grai n type name that grains Dili ng th is rale must have. 

ARIfY liither ^SINGLE or [MULTIPLE. A rale with arity : SINGLE can have no more than one 

grain filling it A role with arity [MULTIPLE can have an arbitrary number of grains 
filling it. 

iUAWE -SOURCE Optional. The name of a nolc used to help derive names fur groins that will fill this rule. 


Defining. Process Types 

I VtieCSi cypi-ss 41 re defined w ill* DEI IN [. - P ROC E 55 - T Y P E urtd culls have the furm: 

( D-EF INE-PROCESS-TYPE iVAWf VHPUT-SPIC OUtPUT‘$PlC STREAM-VAR 

QFSCRTBF-FQRM fcREST C0N5Tfll/Cr-F(!lRW£) 

' I be name of Hid pn>ecxK Sype. 

A listed' input role ueiicripEiuns | discussed abuvcji 
A list of output rule descriptions. 

A variable name that will be bound to the output stream when OESCRlGE-FDffM and 
COMSTRUCi-FORMS arc evalu mi. 

DESCRIBE-FORM 

A form in he evaluated an order to describe the processing represented by an instance of 
ibis process type, When the form is evaluated, each rolemame will be bound to die names 
of the grains playing the mL-e. Also, the symbol named by $ TRF.AM- Wfi will be bound to 
the output stream. 

CONSTRUCT-FORMS 

The forms to be evaluated in order to accomplish the processing represented by an instance 
of the process type, When Ihesq forms arc evaluated each of the role-names and the 
symbnl named by S’7REAM-VAfi will be bound as menUuned above. 

Figure 4-1 contains die process type definitions for Lisp corap nation and Lisp binary 1 lording. The 
defi nit IOC. for : l- ISP-Cd HP 1L£ spcci fits, that Lhcre arc twn input roles, SDUfiC E and DEFINITIONS, and a 
single -output rile, SIN ARY. SOURCE has singular :irily and must be filled by a :LISP-SOURCE grain. 
DEFINITIONS has multiple arily and can only tre filled by ; LISP-IMAGE grams. BINARY has ungutai 
aritv and must be filled by a : LISP-S l NARY grain. The describe form produces descriptions like: 

"COMPILE PARSER,LISP" 

I he construct 3'brmt, produce the grain playing the BINARY rule by Compiling the grain playing the SOURCE 
role. The construct forms also cause a notification of the compilation to be sent to die output stream. The 
uotlffcatkin looks like: 

"COMPILING PARSER,LISP,G* 

Processes often depend on grains not explicitly mentioned in tbeii invocations. For example, in languages 
that rely on objects to be specified or loaded before objects that refer to (hem can be oornpilecL (be 
compilation process ;ypc must include .i role ilia! is used cupiure dial dependency. Ihe role 
DEFINITIONS is treed in ■ L ISP-COM PI LE in order Ln express the need foF some things £o he defined 
before a 3 .iap groin can be compiled. Jbe link between Lhc g-nude fur DEFS. IMAGE and the p-nodc 
representing the compilation of PARSER. LISP in the task mudd from figure 4-1 k. an example uf sueh a 
dependency hoisig modeled. Another situation in which it is necessary tu model a dependency not made 
explicitly in command line invocation is for C compilation, lhc ;C-C0MPlLt process type has the rote 
INCLUDE to represent the dependency between a file and lhc files that it includes via the C tfINCLUDI 
mechanism. 


NAME 

INPUT-SPEC 
OUTPUT-SPEC 
STREAM-VAR 


(DEFINE-PH0CES5-TYPE ; LISP-COMP 11E 
( ( SOURCE :L1SP-S0URCF. t SINGLE) 

(DEFINITIONS alSP-l«ftCE MULTIPLE}} 
((BINARY ;LISP-BINARY :SINGLE SOURCE)) 

OUT PUT-SIREAM 

(FORMAT OUTPUT-STREAM "-^CEiKPILE -A” 

{PATHNAME-MINUS-VERSION SOURCE )) 
(FORMAT OUTPUT-5TREAM "-JlCOMP I L IMG -A" SOURCE) 
(COMPILER:COMPILE-FILE SOURCE BINARY) ) 


-SOURCE INPUT ROLE 
iDEFINITIONS INPUT ROLE 
;BINARY OUTPUT ROLE 
- STREAM-VAR 
;D£SCRIBE-FORM 


;CONSTRUCT-FORMS 


(Of F 1 H E - PROCESS-Ti PE : LI SP-f.OAfi-8 IN 
((BINARY iLlSP-BJNARY :SINGLE) 

(DEFINITIONS :LISP-IMAGE MULTIPLE)) 

((IMAGE :LISP-3Mft&f ;SINGLE BINARY)) 

OUTPUT-SIREAM 

(FORMAT OUTPUT-STREAM "-ttlOAD ~A H 

(PATHNAME -MINUS-VERSION BINARY) ) 
(FORMAT OUTPUT-STREAM n “ , KLOADlN& ~A’ BINARY) 
(SI:LOAD-fllNARY-FIEE BINARY NIL T)) 


[BINARY INPUT ROLE 
■DEFINITIONS INPUT ROLE 
lIMAGE OUTPUT ROLE 
;STREAH-VAR 
[DEStRIGE-rORM 


;CONSTRUCT-FORMS 


I■ Eg u r l - - 4-i: PriMSS Type Definition* Knr I .isp 


4,4 P~ INodes 

Eiach p-node represents^ princes re he invetked un the grains attached lt> its input ports to produce the 
grairti attached to its output porLv Koch rule ]n a process type is represented as a port in p-nodes of that type. 
The grain lype of each g.-rmde attached tu a pun must be the same as the grain type ashneiated with the rote. 
A description of the processing represented by a p L (10de and the g-modcs attached lo its ports cM be pr-uduced 
by applying DfSCRJfl'f-FORM from the p-nodc's process type object to the p^node, The processing 
represented by the p’tiode can he clone by applying CONSTRUCT-FORMS from the p-ncjdc’s process type 
object to the p-irede- 

T-'ignn; 4-1 contain!; an expanded view of the p-node used 10 represent the compilation of PAR5ER . LISP 
in TTNYCOMP. 



Elgurc 4-4: 9 ^ponded P j Node 










4.5 Task Graph Constraints 

J ask graphs arc cimstraincd in the following ways: 

1. Task graphs arc -aizyclk:. A cycle in a graph would imply that ysne gram was needed ill order to 
construct itftdf. 

I . I he parent iif a g-riode, if there is urn.’, must he a p-nodt 

J. A ^-riodc Liti 1 ! have no more than ouc parent, 

4. A pods without a parent represents a source grain. 

5. The children L>f a g-node, if' Lhcie arc any. must he p-nndes. These nodes represent processes that 
depend upun the grain represented by the g-node. 

6 .. A g-node without children represents a goal grain. 

7. The children (if a p-nodc must he g-nodes. Ihcsc g-nodes represent grains derived by the process 
represented by die p-node. Kadi p-rtnde must have at IcasL one child. 

in other words*, task graphs are (Cyclic graphs which begin with gouges lhai represent source grains and end 
with g’ nodes that represent goal grains. I Tic g- nodes are separated by p-nndcs Lhat represent (he processes 
that derive later g-nodcs from earlier ones. 

Figures 1-2, 2-1. and 4-1 arc examples ot well formed Lusk graphs. 


4.6 The Construction Algorithm 

Figure 4-5 contains tire Algorithm used by BUILD to perform the construction modeled by a task graph. 
This algorithm is similar m (he one used by MaKP and nnt^YSn-TM (figure 1-3}, the primary difference 
hetween Ihc two algorithms is in how Lhey make use of creation ctaLcS (O determine when construction is 
necessary, The maku algorithm uses file creation date ordering between input and output grains, in order to 
infer dial an input has changed (and therefore construction is triggered). In practice this method works, 
how-cver, it relies on several assumptions that are not necessarily true, 

MaKF and rau-'SYKTFM assume that files with the same name but different ex tensions arc related. Fur 
instance, they assume IhaL MAIN.0 was created by cumpiLiug MAI hi, C. While this is a reasonable 
assumption, it does not have tu be true. Nothing prevents users froEti renaming files and there fure, there is no 
guarantee that WAIN .0 actual ly came from HA IN. C. 

[f an output grain contains a file creation date that is newer than all of the input grains used to produce it. 
then MaKF- and PFITJYS.TEM assume (hat the output gram docs not need tn he rebuilt Hnwever, there is on 
guarantee: that filecrenjicm dates have not been tampered with. 

KLJIE.D does not use file creation dale ordering to infer that an object has changed. IHJILO compares a 
grain's ingredient li-u with die ingredient list that would result if the pretesting modeled by the tusk graph 
were done. If (fie ingredient lists match, then (fie construction is not done. 

The prototype impitnienratLoii of in.itt n keeps a separate data fitc that contains grain creation dates and 
ingredients. Such a file would rtot be needed if the underlying environment recorded the ingredients used to 
produce An object, 'lltc Mecs environment [Milchell 79, Schmidt 512] keeps this in formation and cxploils it in 
order to determine when processing needs tit be done. 


(DCruil CONSTWUCT - G - N DDE (C-MODE) 

(CDMD ((SOURCE-INODC-P G-NDDC) T > 

((OR (NON “EXISTENT &-N00E ) f INGREDIf NTS-CHANGED &-NOOE}) 
(HAPCAli IT CONSTRUCT-G-NODE (INPUTS (PARENT G-NODE ) ] ) 
(BO-CONSTRUCTION (PARENT G-NOCE))))) 

(DEFUFJ INGnEDICNITS-CHMGED (G-NOPE) 

(NOT (FQUAU (INGREDIENTS G-HODE) 

(DERIVE-INGREDIENTS G-NOUE)))) 

(OEFUM SOURCE-NODE -P (fi-NODE) 

RETURNS T IF AND ONLY IF G-NOOE 
:r REPRESENTS A SOURCE GRAIN 
3 

(DEFUN NON-EXISTENT (G-NODE) 

li RETURNS T IF THE GRAIN REPRESENTED BY &-NOOE 
;; GOES NOT EXIST 
) 

(OiFUN PARENT (G-NODE ) 

il RETURN THE PARENT P-NDDE OF G-NODE 

) 

(PEFUN INPUTS (P-NODE) 

RETURN THE INPUT G-NODES OF P-WODE 

> 

(DEFUN DO-CONSTRUCTION (P-NODE) 

;; PERFORM CONSTRUCTION REPRESENTED 0Y P-NODE 

3 

(DEFUN INGREDIENTS (G-NODE) 

;; RETURN TUE INGREDIENT LIST USED TO CONSTRUCT 
;; THE EXISTING VERSION OF G-NODE 
> 

(DEFUN DERIVE-INGREDIENTS (G-NODE) 

RETURN THE INGREDIENT LIST THAT WOULD RESULT IF 
;; A NEW VERSION Of G-NODE WERE CONSTRUCTED 


Pi£iire 4-53 BUILD ConsUiKlion AlgurLthm 


5, Construction Requests and Task Graph Derivation 


After a System has been modeled wish OE fHOBEL, ISUIE n can be called upon lu handle construction 
requests k■ i i|. ibcli request hits the form: 

(GUILD-REQUEST MODEL RE QUEST $0PT ] OKAL MODULE (MODE : N DftMAL)) 

MODEL The name of a model previously defined with GEFMODEL, 

REQUEST The name of a request recognized hy FHJj|ji(g,g ;COMPILE. :LOAD). 

MODULE Jhc name uf a module H> operate upon. If this field is not sped fled then the default 

mcrdulc for the system (as defined with [he : D£ FAULT-MODULE declaration form) is used. 

MlSped fiCS intc of several construction modes. Construction modes arc discussed bdow, 

The prototype implementation of HLUJ-IJ has three Construction modes that h-chtiwc as follows: 

; NORMAL Describe .lI I of the consun.igfron to be dome, and ihert ask the user if FUJJU j should perform 

the construction just described 

: D E SC RI Ji E E Jcsgribc al l of the Construction L-u be done but do not perform it. 

i NO" CONFIRM Perform ibe req uired construction w itbout describing it first. 

Sample nc.rn.n- requests are; 

(BUILD-REQUEST TINY-COHP ;L0AQ) 

(fid | 10* REQUEST" LIED :LOAD DRIVER) 

(BUILD-REQUEST UN! eLOAD DRIVER i DESCRIBE) 

Once a request has been received, a three step process is executed for each, grain in the module stated in 
Uie request. 'Ibis pme-R5 creates a task model for tile request which is then processed ill the munner outlined 
an chapter 4. The three steps arc: 

1. Model the construction that can be deduced from the request without considering any references. 

This phase is called- pre-ttfirtnee mquesJ processing. 


1. Model thceunstnietinn lhat is Implied by the references that Involve the module associated with 
die request. This phase is called rtftr?n(C p^sCtittfig. 


3 . Model the construction that can be deduced from the rpqucsl and the graph built from the earlier 
sLeps. I bts phase is called po$r reference requesi processing. 

After die pust-rcfcrcnec processing has been completed die task graph. is complete and can be used to direct 
the construction needed to handle the request. 

He fare the construction pmcess can be explained in detail it is necc&ary to present the functions used IP 
view and manipulate task graphs. 


5,1 Vicwinji u mJ Mini pula tiny Tu.sk Graph* -■ A tTLSS 

Consider UlO fbHiiwing List graphl 



■* sounct 


HlNAKlf 



11 1 HAKV 



L [SP-COHPLLE 


: I ISC' LCAD-B 3 N 


Starting at Li p-lKKk, (he p.ilh [l> any of (he g-nodcs connected to One uf ilS pons can hfl specified by 
mentioning the- ftiifnc of (lie port desired. lit the task graph above, starting ill Lite 3 LlSP-CQHPILf pnnde, 
the Hep E I N AKY leads to DE F S.. B1N. 

A step from a g-ttnde to a p-IUkle call be described tty specifying ike process type of the cimnccrcd p-nodc 
and the role played hy die g-nodc in (he p-node. In the Sample task graph above, die step (B I NARY 
3 U SP -CQHPILL Stirling al &L F S. B1N lends tu (fie : LISP “ COMP 1L£ p-nodc. 

Paths arc fttfincd by listing Slops: 

^'Ibe path {{SOURCE : LISP-COHPILE} BINARY) Starling at 0EF5.LTSP lends Lo 
OEFS.BIN. 

- Thepilh ((SOURCE tLISP-COMPILE) BINARY (BINARY :L15P-LQAD-B IN)) sorting 
at DEFS r LISP leads tu the : L ESP-L0AD-RIU p-nnde. 

■ The path 

{{SOURCE ; LISP-COMPILE) BINARY" {BINARY 4 LISP-LOAD) INABE) 
starting at DEFS. LISP leads (p DEFS. INAG£. 

■ Ihc pad: 

((IMAGE :LISP<0*0) BINARY (BINARY :LlSP-COMP HE) SOURCE) 

Starling at Of F5, IMAGE leads ds DE F5. LISP, 

The ACCESS family of functions are designed tn provide a straightforward mechanism for both viewing 
ar.d mampnlalLTlg task graphs. These functions are used heavily during the task graph derivation process, 
There arc three functions, ACCESS, ACCE55+, and ACCESS*, each of which is SETFaMe, The ACCESS 
functions have (he form: 

(FlMCTlQH WPC PATH) 

FVNCTJON ACC E 5S,ACCESS^,or ACCE SS *, 

NODE Either a pmodc or a g-node. This node is used as the nsot nf the path to be traced by 


ACCESS-FUNCTIOn. 


PATH 


A list of steps to i>e traced from NODE. 


Hie functions behave in die following manner: 


ACCESS 


Traces PATH from WOOF and rctuniH the last node encountered, An error is signalled if 
any step in PATH cannot he [raced. An error is signalled if there could be more than one 
node that satisfies the path (raced. 







ACCESS* I filet's PATH from flV)DE and returns A lisL of nodes that satisfy the [Kith. An emu is 

signalled if any step in PATH 1 -cannot he 1 Aided. 

ACCESS 4 Trardt PATH fnwi NODE and returns the single msdc chut ftiLi^fies ihe path. An error k 

signalled if there cnuld be mure than one node ih.ii KutklKcs PA tti. Ne* nodes arc erected 
if steps ii't PA TH du not exist. 

Any ACCESS Mil that returns a single tvodc may he used tit specify the rout of another calI to ACCESS, in 
inher words, the following two calls tire equivalent: 

fACCESS Mb E (STEP1 STEPS SIEP^)} 

(ACCESS (ACCESS (ACCESS MODE STEP!) STEP2) STEPS) 

HachoFthe ACCESS functions can foe SEtf ed. Calls have the form.: 

(SETf (ACCESS ROOT-NODE PATH) ENO-.NDDF) 

Einiurcs dial future tails Lu ACCESS wiLh ROOT-NODE and PATH 
(i.C.. (ACCESS R00T‘NDUE PATH)) will return END-NODE. 

(SETF (ACCESS* ffOQr-A0.DE PATH) A/Q0E-US7) 

Knsures Lh.jt future galls to ACCESS+ with RQQr-iMthflf and PA7A 
(Lev, (ACC E S S + ROOT-NODE PATH )) will mtu m NODE - L 75 T, 

(SETF {ACCESS' *007-NODE PATH) FMMUODE) 

(insures thm future calls (o ACCF S$" with ftDOT-NODE and PATH 
{3.c. (ACCESS' 1 flODT-ZVOOE PA TH )) will return Ffc'Q-WODF, 

The ACCESS fu actions d iffer in how- they handle steps (fail carmen be traced, and what (hey dn when & 
path description fan* out, If ACCESS or ACCESS* eneoisrucr a missing link, ait error ]S squalled. ACCESS’* 
ar.d the SETF fiiiKtaons will create the lin k and continue tracing the path. 

A fanout condition occurs- when an aLLentpt it made to trace from a ;ML)LT I PL El arity port of a p-rtude, uf 
when more than one p-node satisfies [fie role-name/pro^hH-typc-narrte constrain? tracing from * {^ncide. 
ACCESS, ACCESS 4 and theit associated SETF functions signal errors if fanout is cncnunlcned, ACCESS* 
will continue iTaeiing down all paths and returns the list of nodes iluii satisfied the path description. When 
SE TFed, ACCESS* will signal an enprif fanout is encountered before the last step in die path description. 

In Lisp Machine Lisp fWeinreb and Moon Si] and Cnmmon Lisp (Steele JM|. the special Form PUSH Cad 
he used For functions that are Sf f Fable. PUSH can be used to add a g-node to a port. For example: 

(PUSH SQME-G-BODE {ACCESS* P-NODE SOME-PATH)) 
is equivalent lot 

(SETF (ACCESS* P-NODE SOME-PATH) 

(COBS SOME-G-NODE (ACCESS* P-NODE SOME-PATH))) 

The SETF forms and ACCESS* can makr additive changes (o the graph When a function needs to create 
a g-nude and link a to a p-node pint, a name needs to he synthesized For the new g-nodc. Ilic name of each 
g-node resembles a filename in that it has two parts, a primary name and an extension. In order to synthesize 
a g-nt^de name, (he function copies the primary part from the grain attiched to Lhc port specified as the 
NAHE-SOURCE port for the port being linked to (see the paragraph about role descriptions in chapterd), An 
error is signalled if a Function needs to derive a g-node name In link to a port that lifts no NAME-5 OURCE port 
associated with it. the ex tension of a g-nude name is derived From its grain type object, If the grain type 
represents files, then die extension is die default-filcnamc-dxtcnsior, otherwise, it is the name of (he gram 
type itself. 


5-- licquesl Ihtndkrs 

Request handlers ::pjLiIV the Uisk graph dmvaliLui step* chill L-iin ho Liken whenever llw request USHCkued 
with rhe handler has been made, witlkniiL tmisideriug 4iisv rcltercncc dcctitn.itii'ifi’i. Requests 41 re identified *i(h 
request signaling I "ui.Ii like k-l-utw si;,!i-H., --d. I'wrli :^i f -: -i; -i :i ■ •> rums :^ ;i lie'.ik. a r.-qiiv-si 
name :md 41 grain type miiiie. h’nT exumple die si&nirture: 

i:CDMPlL E :LISP-50URCE> 

dentrfles (he handler designed in build p^in of the lasi graph needed Lo accomplish thecompilation of a lisp 
source gra in. Jhc signature: 

STYACC iYACC-GRAMKAR> 

identifies the handler that will build pari of the task graph needed to invoke YArr on a .grammar. 

Nut all possible ^.ip imUu rc^ will hasc handlers defined for (hem. F-'orexample the request signature: 

<:COMPILE :L FSP-BIHARY5 

identifies a nonsensical request. 

Pire-reference request handlers are used to construct the parts of a task graph which win be needed 
regardless of the ramificirtions of references. For example, in order Lo model Lhc enmpihtinii of some 
: LISP-SOURCE gram, G. LISP, the following links- can be amide without cnitsidering any references; the 
g-node representing G. LISP should Ik linked to die SOURCE port of a : LISP-C0HPILC p-nodc, and ihen 
the Cl nary port of tills jvnode should be Jinked to a ft-nodc representing the binary version of G. LI SP 
G.BIN). 



Post-reference request handlers are used for modeling processing that can only he deduced after the 
implications oFthc references are added to the task graph, At this lime it has not been necessary to u-sc a post 
reference handler, however, they arc included hcrausc there may be situations where Lhc;r use is appropriate. 


Defining Request ITandlcrs 

htcquest handlers are defined with Q E F l Fi£- ft EQHEST-RAMBLER. Calls have the form; 

(flEFISJE-REQUE5T-HAMDLER (REQUEST GRAUt-TYPE-NAME PRE-OR-POST} 

(kR&$) 

&fiDDY SQ0Y) 

REQUEST ['he name of the request betng handled. 

GftAIAI-TVPE-iYAR£ 

The type oFthc grain that Utc handler is for. 

PflE* Off-POST : PRE indicates (Itat this is a pre-reference- handler. iPOST indicaies that (Ms is a post 
reference handler. 



AflCS 'ITiC names of the variables passed to the handler. There must be at least HEW element in 

[hisJkt, Ihe first ARC will be bound tl) the g-node associated wills the request when BOOT 
eevduatcd 

BODY The humus that constitute the handler. I’hty are evaluated with the arguments passed to 

die handler bound In the variables named in Aflta-5, 

AH requests made by user? have a single argument. the name of the Hindule (haL (he request is intended for. 
Handlers may also make requests, and these Tequ«isean Contain mure than one argument. The handlers for 
the t LDAD+ and ;INCLUDE* tasks presented in Appendix E arc examples of handlers usinji additional 
arguments. 

Figure 5-1 contains the request handler dcllniLions fur I Jsp Compilation and itwding, 'ITic IItkL handler ls 
invoked When 3 : COMPILE request is made on a : L15P-SOURCE module. It uses ACCESS* to ensure that 
the task graph being derived models the fact that Hie : LISP-SOURCE grains an the module need 10 be 
compiled. 

‘Ihe second handler k invoked when a : LOAll request is made on a ; LlSP-SOUftCE module, l"hc first 
Mil -:. !:•..! :ro v.nd'cr doe • r- ; ■ ■li re i i!I:-M■ L. f :n -.adi :H th-- : •* i- " ihe =■ ISP-SOURCE 

module, and [hen il models the fact thal the ;BINARY grains produced by compilation need to he loaded. 
Handlers ensure that UiSk $fiiph paths exist. After a handler has been invoked on a grain mice, additional 
invocations will have no effect ] hereto re, uisk define rs need only he eoncemed thaL the proper handlers arc 
invoked at least once and dn not need to worry aboul additional invocation!. 

(DEF|»E-ftEQUE£T-HANDLCR (:C0MPILE iLISP-SQUKCE iPRE) (SOURCE-NODE) 

(ACCESS* SOURCE-NODE {(SOURCE :LISP-COWPILE) BINARY))) 

(DEFINE-REOUEST-HAN-OLCR { :LOAD : LISP-SOURCE ;PRt > f-SOURCE-NODE ) 
(PROCESS-REQUEST iCOMP iLE 50UHCE-NOCE) 

(ACCESS* SOURCE-NODE {(SOURCE :LISP-CDMPILE) BINARY 

{BINARY tLISF-LOAD-BIN) IMAGE))) 

Flgti re 5 1 !: Request Handler Dc HJlitiens for I -kp 


5.3 Reference Handlers 

Reference handlers realize the amplieaiitius references upon construction graphs. The eonstrerction 
implications Of a reference depend upon die kind E>r reference, the request, and which pan of the reiercrure 
(right OF left) the module participating in the request hcLungs to. Each handler is identified by a reference 
handler-signature that Includes five fields: the LhTce fields fnati the reference signature, the request name, and 
a participation marker (either; RIGHT nr ; LEFT). Sample signatures ire: 

<<;CALLS eLISP-SCURCE tLISP-SOURCE> <iLOAD :LEFT>? 

<< rCALLS ^C-SOUftCE :C-SGURCE> <rCONPILE :ftIGHT>> 

«:MACRO-CALLS :LlSP-SOURCE tUSR-SOURCE> <:CQMPILE :LEFT» 

Not ull references are reLevant to every request made. For instance, the reference 
(:CALLS LlSP-SOUflCE-1 LISP-SOURCE-2) 

has nn implications when ,1 request is made to compile LISP-SOURCE-1, However., if Lhc request Is u> load 
lisp-source -1 fur execution, then the reference implies that LISP-SOURCE-? needs to be tuaded. It is 
also important to recognize that the dircccicwi of the reference matter*. IAk example, the reference shove ho* 
irn plkatiivns when LISP- SOU RC E - 1 is loaded, hilt, it ha* none when LISP-SOURCE -2 k loaded. 


(h-firimji He fete net Handlers 

Reference hand lers are de fined with DE F IN E * ft t F F ftf HC E - KANO L E FI. Calls have the f orm: 

(OEF!ME-REFERENCE-HANDLER {{REFERENCE LEFT-TYPE RIGHT-TYPE) 

(RFQUtST DIRECTION)) 

(ARGS) 

•MJWY A0J3V) 

Rf Ft RE MCE 'I "he name of the reference being handled. 

LEFT-TYPE The grain type ofthe left (first) module in the reference. 

RIGHT-TYPE line grain type of die right {second) module ill the reference. 


REpUEITT 'Jive name orthe request being handlecL 

DI fi ECTION Hither t l.f F F err rRIGHT. t'his field rdentrfics the module that the request being, handfed 

refers to. 


ARCS 'ITw Eiamcs uf the variables p3KKd to the handler, these wall he bound when BODY Is 

evaluated. 'ITverc must he at least two dements in diis list. L'hc first ARG wifi be bound to 
the left grain of the reference. The second ARE will be bound to the right grain of the 
reference. 


600 F The forms that constitute the handler. They are evaluated with the arguments passed to 

the handler bound to the variables named in ARES. 

Figure 5-2 ennui™ reference handler definitions for Lisp compilation and loading, the find handler 
models the fact that the grain represented by CALLED-WOD-E needs to he loaded, and that the resulting 
:LISP-IMAGE grain plays the role fttFINITIOAS- in the compilation of the grata represented by 
CALL IMS-NODE. The second handler ensures that the grain represented by ;CALLED“NOlH is loaded. 
Note, while thu-w handlers arc sufficient to handle the cUilimofl module interactions for Lisp system^ they arc 
not sufficient tq handle all uf the ways that Lisp modules may interact, Mom handlers would need Cu be 
defined in order to pr&periy handle till of the ways that Lisp modules can interact. The prototype 
implementation of BUILD dws not include these additional handlers at this lime. 

hlild guarantees that reFcrence handlers arc invoked after pre-reference request processing and therefore 
handler writers may safely assume that die effects of pro-reference request handlers will already he present ta 
dw graph. For example, the :MACRO-CALLS handler discussed above assumes char the compilation of 
CAL 1.1 N G - KOD E has already been modeled. 


5.4 A Task Description Definition Lit ample 

111 is section presents an example of it laslK description definition, 'l'hc task defined is called 
; LI ST-SOURCE -CORE and it will produce formatted source code listings fora : LISP-SOURCE [Module and 
ally t LISP-SOURCE modules that it references. All of the defining forms for i LI ST-SOURCE -CODE arc in 
figure 5-3- 

Hist, the J LIST-LISP-SOURCE process type is defined. Instances of this type have a single input role 
called SOURCE and a single output role called LIST t NO. 'Jhc fiinctinn LI ST-LISP-FILE Is called t )0 
produce the grain filling the output role from the grain filling the input role. 'Jhe request handler for the task 
is very simple, it models the Ext that the source gram to he listed will play the role SOURCE in a 
: LIST-HSR’SOURCE p-nude and that a g-fiotfe should be attached to the LIST IMS rule of that same 


tvnijde. 'Ilic two rfilercnce handlers specif) 1 dlii[ graiira wbsth arc called by ;i {.ruin being listed should 
thetnsdvL’S be IjsLltL 

: L 1ST “SOURCE -CODE Shows (he virtue ^riwcpinf system models scparjilc frutri in limnalUHl about 
tastes-: uncc ict defining, limns ate evaluated, Ibrniitited listing may bcuhuibied for any previously modeled 
I isp system withum altering any system mtJdcLs, 


(DIF IKE-REFERENCE-HANDLER ((: MACRO-CALLS (LISP-SOURCE : L I5P-S0URCE ) 

{:COMPILE [LEFT )) 

{CAL LI NOCALLED-NOOE) 
fPROCESS-REQUEST :LOAD CALLED-NOOE) 

{POSH (ACCESS CALLED-MODE ((SOURCE :LI5P-CDMPILE) BINARK 

(BINARY ;LISP-LQAD-BIN) IMAGE)) 

(ACCESS* CALLING-NODE ((SOURCE jLISP-COMPILE) DEFINITIONS)))) 

(DEFIUE-RETERENCE-HANDLER {{[CALLS [LISP-SOURCE (LISF-SDUfiCE) 

(:LOAD [LEFT)) 

(IGNORE CALLED-HODE) 

(PROCESS-REQUEST [LOAD CALLED-NODE)) 

Fiji lire 5-2: Rcfcretice Handler Definitions for I jsp 


(DEFINE-PROCESS-TYPE :list-lisp-source 

((SOURCE [LISP-SOURCE :S]NDl£)) 

({LISTING [PRESS [SINGLE SOURCE)} 

OUTPUT-STREAM 

{FORMAT OUTPUI-STKEAW "-XLIST -A" 

{ PAT HNAMf -MINUS-WHS ION SOURCE) ) 

(FORMAT OUTPUT-STREAM "^LISTING -A H SOURCE) 

(LIST-LISP-FILE SOURCE LISTING}) 

(DEFINE-REQUEST-HANDLER (:LTST-SOURCE-CODE (LISP-SOURCE :PRE) 

fSOUPCE-NOUE) 

{ACCESS' SOURCE-NODE {(SOURCE :LI5T-LISP-SOURCE) LISTING))) 

(DEFINE-REFERENCE-HANDLER f f:MACRO-CALLS rLlSP-SOURCE (LISP-SOURCE) 

(rLTST-SOURCE-CODE (LEFT)) 

(IGNORE CALLED-NODE) 

(PROCESS-REQUEST :LIST-SOURCE-CODE CALLED-NOOE)) 

{ DEF INE-REFERENCE -HANDLE I! {{[CALLS (LISP-SOURCE : L ISP-SOURCE ) 

((LIST-SOURCE-CODE :LEFT)) 

(IGNORE CALLED-NODE) 

{PRDCE55-REQUEST [LIST-SOURCE-CODE CALLEO-NODE)) 

Fi(JUr* 5*3: Definition Fur (LIST-SOURCE-CODE 


6. Reprise 


' I Tii s chapter Infill ignis sc o* :il us| k\ \s < -f hi i> ihm have hoc r. n rrso nterl ir :-i< rep* Ml I "he 11 rsr -in •[ .1 m 
summari/ci how HUH II 0 vCK 1 ini.CS line didieullics I^udatcd with existing tools (see chapter 2}. The second 
stelLUil dbcusSCS HUM is’k construction framework. and how H provides a base for describi ng new tasks within a 
•sialic framework (toil conceal* many few level details from the task defincri 'Hie final section proposes ways 
Lh:i1 IHJH.IICUUld be extended EO provide capabilities nrH found in existing lends. 


6.1 BUILD Compared With ExNling Tools 

Phrased in terms of inter-OUHtuIe refercnets. !Tic TIUIIJ) s,yslcm modeling mcdlatism allows uiers to 
describe uyslcms in terms. thee arc natural for them. SHJIIJJ system models are CaSici Id urldcr'i.laii d and they 
provide more information than the construction directive (lists used by enisling tools. 

User dcfinuhlc task, rksenprions. hui.p’s uist description mechanism is responsible tor the fuct thru inm.n 
is not constrained to Some embedded set Of task*., liy separating system, models and task dcseripiirmH, rn.LEJj's 
knowledge about construction ran he fluidified without requiring LhaL system models be changed. However, 
if a Itew tirik is sensitive 10 a class of references previously ignored, then editing models will have [it be 
updated. 

Iniernkslhite trains are n<n referenced, The only grains that arc referred to in a system arc die source 
plaints that comprise mcsdules. While imenmediale grains arc used in HULUH's Lask graphs, these grains never 
appear in system models, 

,\M source grains mast he referenced. All of the sourre grains Lhal participate in a System either reference 
Other grains in the system or arc referenced by Other grains in the system. 'IhcTcr'nrc. since ruru.D models 
encode system referencing patterns, all of the source grains i(l a system must appear in any well formed JKU11.D 
model of that System. 


6.2 BUILDV Const ruction Frameworlt 

□lild provides procedures which guide the construction process. These procedures include hooks for the 
components of usct supplied task descriptions. The set of freed procedures take ewe of low level construction 
details that are common to all tasks and allow task definitions So contain just the details that arc relevant lo the 
particular task being defined. 

The task graph representation and analysis algorithm provide a uniform way no describe and perform 
system maintenance tasks. New process types and gram types can easily be integrated into task graphs. 

The ACCESS family of functions pnovLde a general way for viewing and manipulating task graphs that 
isolates handler definitions from the low level mechanics of instantiating nodes,, matching gram types between 
g-nndcs and p-node pons, arid actually linking. nodflS together 

The task graph derivation algorithm ensures that pre-reference request handlers are invoked before 
reference handlers and that reference handlers arc invoked before posi-referciKC request handlers. This 
algorithm is also responsible fur translating module references inio a series of handler invocations, one for 
each grain involved in a rclcrcncc. Finally, the task graph derivation algorithm ensures that circular 
referencesfi,e., (: CALLS A B) {:CALL5 □ A)) do mu cause in finite loops during reference handling, 

HU II-P’s construction framework allows lask dr finds L" i.mc n irate on the significant details of the task 
hemg defined (e.g., wfud process and grain types arc used.. Wh@t references are relevant and how should they 
he handled etc.) and isolates them from low level details (c.g„ Lask graph analysis, node instantiation. etc,). 


6J Lxleriiiiimun IlL'lLD 

ItUtm provides it mmc graceful way iff modeling sysltins than existing, Luul&, yCL It does nol provide 
gicnk'i ■:■ 1 'i.jhilii il-s. I his section proposes extensions let uuiui that would allow it lo provide a wA of facilities 
tlut other iunls tin mst. Hie extensions iire automatic dcri vaiioii of system specifications from sluice code, 
support fill patching and similar maintenance styles, and file hi corporation Of LllC nature of module change 
into the PKonstnictiu-n algorithms. 


Automatic Derivation or System IJeseriplions 

I he HUM IJ modeling mechanism provides a natural way to describe systems hut it does not ensure that Lhg 
descriptions are complete or correct. Designer? are still required to generate system models hy tmnd. A tool 
that amid denve system models from source code would relieve designer of Lhc chore oFhuilding system 
description tiles. 

For simple languages. an aiuilyy.er could build a great deal OF the model and locate areas that might 
present difficulties, for example. in most C systems nil Of the dependencies are caused by use of the 
#INCLUDE compiler directive and calls LO c memalEy defined symbols-- the reference a&wrtiotlS frona these 
references could be synthesized automatically. 

While there may be programming environments in which it is possible to mceliuni/e the derivation of 
system models. there are certainty fem^usEcs for which Such derivation would become arbitrarily complex. 
For example, hitman develops an argument against automatic derivation of Lisp system models based on the 
complications caused by macros [Pitman 84], 


Patching 

There are many instances where a System imtintrtincr may want to introduce changes irtlO a system without 
mating sure that the resulting system is consistent;, for example, debugging experiments where small changes 
are introduced to externinc some small parL of thd sysLem. These changes may not be intended to become part 
Of a released system, it may even be known that they will WUSC compilation of some other module Lo fad, 
An other tnsrancc where the ability Lo patch a system is important is when a quicSt fix is being attempted and it 
is important that tfie effects be seen -qure^Lv. I'll is hind nt'change represents a tentative guess on the pan of 
the maintainer. The introduction of such changes into systems must be supported by system management 
tools if such tools are going to help and hot hinder maintained. 

The UEFSV&ti-m patch facility provides some support for producing inconsistent systems. Unfortunately, 
the DEFSYSTPM patching facility makes no use of (he dependency information dial the rest of die tool uses, 
No analysis of the effect of a ptltcl) is available. Nothing guarantees that a patch will even be loaded correctly 
according 10 (he dependency information than k available. For example. if A patch file includes a modified 
macro definition and two calls to it, the calk will not reftr to the new version of the macro unless they are 
placed after the definition in the patch file by the user. 

System management tools should main? use of system models in order Lo support patching. Patch mg 
mechanisms should also supply information about the elToct that a patch may have on the rest of tire system. 
In IU_. II.D, the analysis could he dune by propagating lhc effects of a change through a USi graph find rh.’r 
identifying those mtidulcS that were affected by lhc change but ignored by the patch. 


More Freetse C hange Analysis 

All of die Louis mentioned in this paper (including hum jr} are sensitive to the fict that some change has 
occurred to a module in a system. However, no attention is paid to die nature of (Ire change. Jiy exploring (be 
mature of a change it is possible to limiL the amount of processing done when updating systems. 

If source code is changed in a way that eannoL alter its compilation, there is no reason for the source 
module lo he recompiled, l-or ciuunple. ■compilation s fun fid not he done when source code has only been 


reformatlcd of had CtHrtmcnLiiry .id!Jed. tn it. If a function is qd^JccJ to a module, hut Hep twisting mcxlulcx arc 
upd.iiLed to Contain culls to Ehe now function, iHUhing should h«c done to the C-usting modules. Llni libraries 
tine dependent upon the firsi pass of lint, however, must changes tn the first p^ss of I.ini wifi not affect the 
libraries. 

Change analysis ca n also provide important debugging information. For example, if a module interface is 
changed, but not all of the modul’Cis that contain references tn that module arc changed. there is a possibility 
that an crow of omission lias been made. 

Unlike MAKI : and FUJI I -IX IlHI-TiYSTMM can be extended to include mure complicated predicates fnr 
deciding when changes arc significant. There is nothing preventing a MdSYSrhU system definition from 
using parsers and Source code comparison programs in order to decide when transforniathHte should Like 
place. However, no enhanced predicates- are supplied with linersi i m and none of the DHI-SYSTIiM 
deseri ps iE>iis encountered while preparing thfs paper included definitions of such special i/rd predicates, 

Specialized predicates can cm l> he useftil if they aciiuire less pnEtssing to detcnr.ine that a transformation 
can be a voided than applying the transformation in the first place. For instance, there is no pnint in using a 
predicate 10 determine that compilation of a module can be avoided if that predicate lequircs mwe prucessLng 
[him the compiler. ilUJ]J> car. step around this issue by assuming that il Ls a single tool embedded hi an 
integrated environment in which Lhc tools that are used to modify modules can supply informatiiM 10 HLll.t? 
about the imLure of changes, 

film t> could be extended io provide an interface for communicating information about changes to 
m«>dulec. Ihc information passed lo F 11 . 143 .I] would include ihe name of the grain modified, the kind of 
modification made, and the name of the new (L.c. v updated J grain A new class of handlers called change 
handlers would be introduced to aid in the determination of significant ch anges by the construction algorithm. 

For example* the change assertion: 

( IMBED-STRUCT DEFS) 

would inform I1U1I t> that DEFS has been changed by adding a new structure and Ihcrefnic modules that rely 
on DEFS do not have to be re-compiled. '] he compilation of unaltered modules tan be avoided since there is 
no way for ihem to refer to the new structure. The assertions: 

( : ADD ED-COM MEM" DEFS) 
l :RE-fORMATTED DEFS) 

imply that no changes that can alter the compilation of DEFS haye been made and therefore no re¬ 
compilation needs to be done. 

The change handlers would contain Ei.slir.gs of hnw types of changes, alter (he way in which ^wifiiS play 
their roles. For instance, one Isundler would note that re-formatting a piece of source code does not change 
the way that it plays the role SOURCE in Instances of: LISP-COMPILE, 
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I BUILD Definitions ForC 


UK dcfinkfons used by IHUIIJj In model a l.isp environment hive been given in the Wdy uf LhiH report as 
examples. This appendi* contains die definitions used by uuir.n to outdo! a C nnogmininins environment. 
Jtlcrc air more kinds of commonly used grain types in UNIX ertvtrtjmtirnls than ip Usp en MiffitimCfttS, 
hence (here arc more definitions needed to model id I of the way* that UMX grains can refer to CwCh tuber. 
Cum men Laiy has been added to highlight (he definitions, 


Grail? Type ncfiiiiltons 


(DEMNE-GRAIN-TYRE 
(OEF INI-OR AIK-TYPE 
(Co F INE -I.LHfl I#-]YFE 
(DC FINE-GRAIN-TYPE 
(DEI INE-GRAIN TYPE 


: YACC-CRahNAR V) 
:C-SOLiflCE iCJ 
C-OHJECr 10] 

L -L XI LUlt :£lf ) 

:SHELL-SCHEPT :S£R1R1) 


Process Typo Definitions 

It is assumed LhaL Lhc ftmcLmnH C- COMP IL £ . C-LDAD, and V ACC are available, 

{DEEINE-PROCESS-TYfl C-CBNFIILi 

((SOURCE :C-SGUHCE :S 1 NGLE) (INClUOIS. :C-SOURCE MULTlPli.)) 

((WJICT COR J Ed iSJAWLE SOURCE)J 

STflEAH 

( rORNAT ETPEftl* "-tCOMPTLE -A 1 " (FAtHNAMF -H INLIS - VE HS IOU SOURCE)) 
(FOHHAI STREAM "-TfCQMPI LINC -A' SOURCE) 

{■C-COHPILC SOURCE OBJECT)] 

(IHFSNE-pHMESS-'rYPE C-LOftIF 

((PRIMARY :C-OBJECT iSJNGl.l) {Sf fi(’ianAR v C-OBJECT ;MUt.T|FLEJ) 

{{ IMAGE :C-tKECUTE : SINGtE PR[J4ARY )■} 

STREAM 

{EDRmM STREAM •'-XLINA: -A -{-X -A-}' 

(PATHNAME -H INUS-'VE R 5 ION PRIMARY) 

(NAPtftH A" MAT HNAME -H] NUS -VERSION SECONDARY)) 

(fORMAT STREAM - liL 1 MIC. 1NL . -A -A-)" PhlMAiRY StMMWIY) 

{t-ioan PRIMARY SECONDARY I MACE)) 

(OEF1NI'PROCESS' TYPE YACC 

((GfiAHHAH ;TACC-CRAJWAn ;SING LI)) 

((PARSER .C-SOURCE StHGLE GRAMMAR)| 

STREAM 

(inftMAl STREAM '-1YACC -A" (PATHNAME -MINUS' VEILS ION GRAMMAR)) 

(TORHAT STREAM ‘^XYApClNG -A' GRAWUfl) 

(YACC; SRAMMAft PARSER)} 


RuquL L ht and KcFori'nec Handier* 

The request handler Tor C enmpilatkm meitfels the fma chut Ihe swunoc grain needs in be enmpiled. lire 
only Itfcrenee dial C:in have .in effect hits C cmTtpitotnHJ is r INCLUDES. If GRAIN-1 include GRAIN-2, 
then GRAIN-1 indirectly includes any grains [hut GK AIH-2 includes, ITiC tusk ;J NCMJDE + (described Inter) 
is rcspLrtiSihle For gathering all uf the grains included indirectly hy a grain and attaching die mrresfnuidlng 
f-nodes (he INCLUDES port of UlC tC-COMPILE p node for the grum being compiled. 


;;j : COMPILE :C“SQURCE 

(nr I ]Sil - III Ijlll Sl-naS Jl I B (iCOHPIEE :C-5<KJRCt fRE) {MUfiCI -»&DE J 
(ACCESS* SCKHRCE ■ MtXJE C (SOURCE C-tOUNCf ) OBJECT))) 

(DCF | HE - RE F f Hf nCE - k*N0 L£ R ((: INCLUDES :C-50URCE iC-SOURCi) | ifflttfJU HU)) 

(INCLUDrUC-HOnE IHCl UOEft-ROOC) 

( LIT {( COMP ] I E - PROC ESS (ACCESS SUCUjniHli-HdDL (I SDtlftCL C- COwiPILt))))) 

[PUSH HhClUPEp-MOQF (ACCfSS> COMPILE PROCESS (ElKlUniS))) 
lPROCESS-REQUEST :TMCLU0L+ IHCLUPfn-HOni COMPlLE-PftDCF S"S Ji"Ji J 

If a :C- SOURCE grain calls another grain. Ihcn FMJttU pcssimistieaEly ohuuKS that it indirectly Culls any 
grain, called by iM second grain The task : LOAD+ gathers all of the grains culled indirectly by a grain in 
urder in ensure liiut the proper set of grains is [inked tiigethcr. He lack of a task like • LOAD+ in Lisp is doc 
to the Tact dial in l.isp environments, grams are landed Lncremcntally instead of being explicitly linked 
together. 

■If ;L0AD lO-SQURCE 


{DIE 111 -REQUEST-HANDLER (:LQAO :C-S0URCE : PRE ) (SOURCE-MWH} 

(PROCESS-RE QUEST : COMPILE KNJHtl-NdOE) 

{ACCESS' SOURCE-ntJCII {(SOURCE C-COHPtLE} DEJECT ( PRIMARY C-LOAO) IHAfiF>>> 

(DEFKJi-RIFEREKCE-HANDLEn {{:CAClS :C-£OuRCE :C-SQUREE) {:LOAD :LEFT)| 

(CALLING NODE CAL LEO-NOPE) 

{CET (I'LtUKthG-PROCESS 

[ACCESS CALL 1 SC-*1®I ((SOURCE C-CCMPILE) OBJECT (PRIMART C-LOAP)]])) 
(PHOeF$S-RLQUIST jCOMPILE CALLED NOPE ) 

(POSH [ACCESS CALLED-IKllE £ (SOURCE t-C(SHPUi) OBJECT)) 

[ACCESS-1 LINMWfi-PflOCiSS {StC&N&ARV])) 

(PDOCESS-HEOLnSI :LDAD+- CALLLO-NODE LlUKHC-PROCESS))) 

(DEFINl-REFEREHCl'HANDLED |(;CALLS ^-SOURCE iC-DEJECT) ( :LOAD :LEFT)> 

I>l l J PJL - H Cli't CALLED NODE) 

{LET ((ltht!KG-PROCESS 

[ACCESS CAUL INC-MODf ((SOURCE C-COnf ELE ) DEJECT (PRlHARf C-LOADJ)))) 

(PUSH CAUrn-innE (ACCESS- UNtlhQ-PfiQCESS (SfCOHO-ART})] 

( PRCIC! SS-HI QUI ST :ADMJ+ CALLED NODE LINKING-PROCESS})) 

Sometimes compiled objects are irsed a* source- grains {e.g. iupplied libraries). These definitions encode 
the knowledge needed to handle the loading uf :C-OBJECT grains. 


: LDACh :C-OBJCCT 


(DEFINE-BEANIES I-HaNDLER £:LOAD :C-DfiJECT :PflE] |OBJECT-NODE) 
(ACCESS'' OBJECT-NODE ((PRIMARV C-LOAQ-J IMAGE))) 



(DET 3NE-REFF RE NCI-HANDLER <(:CALIS :C-OEUfCT ;<-SOURCE> (;UMB :LIFIJ) 

(tALl 1 NO-NODE CALL ED-NODE) 

CL ET [{LTMItlNG-PfiOCFSS (ACCESS CALL [ K j MOD I ((PR3 MAH If <-10*0)3111 
(PrtOr-F SS-flFOUEST : COMPILE CAiL L £ b- I6S«E ) 

(PUSH (ACCESS CAUEO-HODE ((SOURCE C-CONf-lEE) OBJECT]J 
(ACCESS* L [KK IUC-PROCESS (SECONDARY))) 

IPH-DCE5S-RIQUES1 :LOAtl* CAillp-#30E LINK!NS PROCESS))) 

; 111 i mi -!: ••. HI ni:i-H 4Aim if (f : CALLS : 1 000. l i i: - h ,i i " ■ i ( : LOAS :lii n 

(CALLme-MODE CALLED-NODT) 

(LET ((LI NK.J IK - PROCESS (ACCESS CAlllNGWtWE (( PRIMARY E-HUB))))] 
(PUSH CAL t MJ-Hdrii (ACCES5+ Lm*] HO-PROCESS (SFCONUAHrm 
(PROCESS-fit OAKS I JEIAIH- CALLED NODE L L h K i MS- PROLE SS ) } ] 


Here arc the handlers for ; I NCLUDE+ and :L0AD+, There arc HO request handle™ associated willl these 
request'!, as ill] of the signiHcariL construction bfiwmaiicm that she* imply anses from rcfcrcocci These 
handlers illustrate die use of more than two values beiny passed id reference handlers, ‘the additional 
Plitr meter for :INCLUDE+ is the :C-COMP11 ( p-jiude which models the compilation to be dtme. I "he 
additional paramnci fui ■ LQAD+ is the p-raidc which models the linking to be dime, 

III ; FNCLWH* :C-50UPEE C-C0Hf(lE 


(Ql FIHE-HF f EHCNCI-HAIWLEH ( ( ; INCLUDES iC-SOUHCI C-50URCI) (: INCLUDE* ;IFFT)) 

(IGNORE INCLUDED-NODI INCtUP1NO-PROCESS) 

(PUSH IK LUO ED NODE (ACCESS* I NtLWlNC- PROCESS (INCLUDES))) 

(PR«ESS-R|gUCST :INCLUDE* 3NCLUDED-NQUI INCLUDE AG-PROCESS)) 


rLOAD* :C SOURCE C-LfiJUf 


(DC F t NL - A £ F I" ENCI-HANDLER (j:CALLS :C-St>UflCE :C-30URCE> ( ;LQAD* : LEFT)) 

(IGNORE CALLED-NQDE LINKING-PHQGtSS) 

(PR0CES5-REQUEST :EGMPIL1 CALLIO-NCflE> 

(*USlP (ACCESS CAUFp-HODE ((SOURCE C-COMPILE) OBJECT)) 

(ACCESS* LINKING-PROCESS (SECONDARY))) 

{PROCESS-RE QUEST :LOAD* CAkLED-wW* LINK INC-PROCESS]) 

(DEFINE-REFERENCE-HANDLER. {(: CALLS ;C-S0UPCE :t- OBJECT) ( : L,<WU>+ ; LEFT )) 

(IGNORE Cfl IL E D- NODE UNKIND-PROCESS) 

(PUSH CAlLED-MOL* [ACCESS* LINK I NO-PROCESS (SECONDARY))) 
(PROCESS-REQUEST :L0Ab+ CALLED-NODE LIRKIHG-PROCESS)) 


iii :L0AD* iC-flflJfCT C-LDAD 

P • F 

(DEFINE REFERENCE -HANOtFR {(;CALLS :C-0BJECT :C-SCHJlO) {:LOGO* iLEFT)) 

IIGKMI CAUL 0-NODE LINK INC-PROCESS) 

(PROCESS-HE QUEST :COMPILE E.4LLED-NODE ) 

(PUSH (ACCESS CAlHO-RCgE ((SOURCE E-EOwPIlE) OBJECT|) 

(ACCESS* LINKING-PROCESS ( SEttUMHY) )) 

(PltOCF Ss-REOUI&T : LOAD* CALlED-KQiFF l 1NK1ND-PROCESS}) 

(OErmi-RE FERE IKE-HANDLER {(iCALLS it-OBJECT :C -OBJECT) { : LOAD* ;LEFT J} 

(IfiltOM CAIUO-NDDE LI1U IMG-PROCESS) 

(PUSH CALLEp-NOK {ACCESS* L INKING-PROCESS (SECONDARY)! 

( PROCESS-HEQtFEST :LOAb+ CM LED-NODE L FFiKI NG-PROCiSS)} 


Hero are Lhc definitions used LO model VAfC's interne Linn with C systems. Ihe handlers capture the Tact 
that y ,\0 (jraiEimdra may include and all other grdins. 

;;; if (ICC ; TACC-li HflNMAfi 


(DEFINE RtQUESr-NAaiMB f ft {:TACC : Y ACC - C P fl«V ft F| : f fi* ) (GSWWAH NODE) 
(ACCESS* GRAMMAR-MODE {{CRANKAR TACO) PARSER))) 


COMPILE :TACC-CRANNAR 


(Dimi-E RE QUEST-HASm! ft { . CDMPILt :lfACG'&RA»'AH ;HHF) (GftAHMA.fi-HOD t) 

[PROOF 3 $-RE.Out ST : If ACC GRAWAR -NODI) 

(ACttSS* GRAMMAR NODE {{GRAWUR TACC) PARSER ( 50 UflCt C-CQHPTLf] aftJEET)}) 

fDmWE-BtflRFHtt-HAfJDlER {( : INCLUDES ; ^ACC-GRANNA!-! :C SOURCE} ( :COMP[LE iLEH)) 

| I ki:u;u JHL-NODE ENCLUDEO-UOQF ) 

(LIT j (COMPEL E-PH0CI$S, 

(ACCESS IKUIDCN3 MOTE ((CRAMMAII rACC ) PAASFP (SOURCE t-COMPEL EJ->>>) 
{PUSH INCLUDED-ROOF {ACCESS* COMPILE - PROCESS (INC!UI.3E S )) ) 

{PIH>Et 55 -REQUEST : INCLUDE* INCLUDED'NODE CQMPIII -PROCESS h}) 


:IOAii ; taCC-Grammar 


(DllI*E -REQUEST -HANOI*ft { iLMG ■ rACC-GRAAtMAR : THF | (GRAMMAR-KOChL J 
[PROCESS-Ri QUEST :COMPILE 5RWMAH-NQPF ) 

(ACCESS* GRAMMAR-N0UE {[&RAWAFI TACC) PARSER 

{SOURCE C-CDHPILE} OBJECT 
{PRIKAflK C-CQaCj) EhME)}) 

f DF F r K F. -R* > t RE WC1 -HANDLE R {{ : CALLS :TACC-GH fWHAR :C-SOURCE) ( ; LtJflEF 

{CALLING-NODE Lal I EG ■ RODE | 

[LET ((LINKINE-PHOCISS {ACCESS CALL S NG - HOST E ((GHANNAfE VACC) PARSER 

(SOUflCl C-CDHPILt) OBJECT 
(PRIMARY C-UJUJJ)))) 

{PROCESS-REQUEST COMPILE CALLCD-HQQE) 

{>U5A (ACCESS CALLED MODE ((SOURCE C-CC*lPILf } OBJECT)) 

(ACCESS* LI^AiNQ-PROCESS (SICDNDARV))) 

{PROCESS-REQUEST ; | OAp* CAL LEO- MODE LI HAIWC-PHOCCSS)) ) 

(DiFIKE-RtrEREMEE-iRANDLEfl {{;CAUS : YACC-GP AWAP iC-3GJICT) { ! L0AO :L£FT)) 

(CALLING-NODE CALLED-1(001} 

(LET ((L1NAEHG-PROCESS (ACCESS CALL JNC-NOTH ((GflANHAR YACC) PARSER 

{SCiinCE C -COMPILE} OSJECT 
{PR rHftRTf C-lOAD)))}} 

(PUSH CALIIO-HOOE (ACCESS* LIN*TNG-PROCESS {SECOHOARY))) 

{PROCESS-RE QUEST : LOAD* CAlLFO-NODE LI NKIkG PROCESS))) 



Here arc the dcfinttiun* used m handle : SHE LL-SCRIPT grains. A request lu compile or bad a shell 
script is inicrpirLcd m mean Unit M of Lhe modules culled by Lhc script should be compiled or Itwdcd. 

r : i 

Hi CQHF1LL : SliLLL-SCRIPT 


I DEFINE-HEF ERFNCE-HANOl.IR (( .CALLS SIeELL-SCRIPT :E SOURCE) f: COMPILE -LETT)) 

{IGNORE CALLED-NODE) 

( PROCESS- RE QUEST ^COMPILE CAl11P- NWHl '/) 

f PE f C h I. - H L H RE NC> - H jLMOlT R {{ : CALLS : SHELL-SCRIPT :E OBJECT) {: COMPILE :LEFT )) 

(IGNORE EALLE0-NODE] 

(PROCESS REQUEST :COMPILE CALLED-NOTE)) 


{OET tiF -OF F FRFNCl -LIA.NOLER ((:CALL5 : SHELL SCRIPT r mC-GRMWAH ) ( ;C0NPELE : LEFT>> 

{IGNORE CALLED-NODE) 

(PROCESS-RE QUEST i COMP |U £*( I * 0- H&OL )) 


err 

■ ¥ ■ 


:LOAn SHELL-SCRIPT 


| OF F THE-RE F TRENCF-'lAHlll ! H {( CALLS . ShLll-SCRIPT :C- SOURCE ) (: LOAD : Lt T T ) ) 

(IGNORE CALLEO-NODE) 

(PRMESS-REQUEST ; LOAD CA|IEP-R*OCEt >> 

(DEUNL-fiETEPENCE-HANDLER ((:EALLS : 5IIELL-5CHCPT :C-O0JECT) (;LOA0 :LEET)) 

(IGNORE tAL Lf U-NUDE ) 

(PRMtSS-REgUlSI iLOAU CALLED-NOOt)) 

(DEFINE - RET ERE NCE -HANn L f R [( ; CALLS i$Hil 1 ,-StRtPT 

(IGNORE CALLED NODE) 

(PROCESS REQUEST : LOAD CALLED-HOOCH 


! TACC-GRAMMAR.! (:LDaD lLCFT)) 


